PAYME / INVESTOR PERSPECTIVE

The PAYME Investment Case

A pre-launch venture building a merchant payment experience for Nigerian businesses, with a staged path into international B2B trade.

PRE-LAUNCH BUSINESS CASEPAYME — PAYMENT MADE EASY
01 / THE BUSINESS CASE

Start with the sale. Build the relationship.

A payment is not an isolated event. It belongs to a customer, an order, an invoice and the next business decision.

PAYME’s thesis is to help Nigerian merchants connect those records, beginning with reusable merchant QR collections and a focused workspace. Repeat merchant relationships could later support more complex supplier and trade-payment workflows.

02 / THE BUSINESS CASE

A narrow first release. A connected roadmap.

LAUNCH WEDGE

Merchant identity + collection

Reusable merchant QR, clear payment references and provider-confirmed status.

WORKING LAYER

Records + invoicing

A workspace for daily collections, outstanding invoices and exception follow-up.

EXPANSION

Trade payment journeys

Selected B2B routes, introduced only after country, currency and partner readiness is established.

03 / THE BUSINESS CASE

Revenue must follow value—not just volume.

The working model has two initial hypotheses: an agreed share of payment fees where the provider arrangement permits it, and optional paid merchant software. Cross-border payment income is a later route-specific hypothesis.

Neither the price nor the margin is validated. Unit economics must account for partner charges, acquisition, onboarding, support, fraud exposure and reconciliation effort.

Review the business model
04 / THE BUSINESS CASE

Build the merchant layer. Integrate the payment rails.

PAYME’S PLANNED ROLE

The merchant experience

Merchant interface, payment-request context, business records, onboarding coordination and first-line product support—subject to agreed responsibilities.

PROVIDER ROLE TO AGREE

Regulated payment execution

Payment processing, applicable verification, settlement and route permissions must sit within a confirmed, appropriately authorised arrangement. No agreement is announced here.

05 / THE BUSINESS CASE

Prove a repeatable merchant workflow first.

Start with one defined merchant segment and a tightly supported pilot. Recruit through merchant associations and trade communities, observe the counter workflow and measure repeat use before expanding distribution.

Association access is a proposed channel, not a signed distribution agreement. Merchant interviews, acquisition costs and willingness to pay remain to be demonstrated.

Review the market-entry plan
06 / THE BUSINESS CASE

What exists. What needs proving.

Available in this release

  • A branded WordPress marketing site.
  • Interactive QR, dashboard and trade illustrations using fictional data.
  • A documented product and commercial thesis.
  • A configurable AI information assistant.

Not established by this release

  • Licensed operating status or signed payment partnerships.
  • Live transactions, paying customers or verified traction.
  • Validated revenue, pricing or unit economics.
  • A committed launch date, fundraising amount or valuation.
07 / THE BUSINESS CASE

Fund the next proof point.

The proposed use of future capital is staged: merchant research and product testing; provider and operational assessment; secure payment-platform development; and a controlled pilot with measured outcomes.

A funding ask should follow a costed delivery plan, team commitments and partner requirements. No investment terms or financial return is being offered on this page.

08 / THE BUSINESS CASE

A realistic case includes its risks.

Key risks include bank-app compatibility, merchant adoption, payment-status reliability, fraud and disputes, support cost, partner dependence, privacy/security and corridor economics. Each needs an owner, a test and a stop/go decision.

Review the diligence checklist
09 / THE BUSINESS CASE

A QR code alone is not a moat.

Bank apps and existing payment providers already help merchants collect money. PAYME must give a merchant a concrete reason to switch or add another tool: better order context, fewer unresolved records, a more useful daily workspace or more effective support.

These are differentiation hypotheses to test, not exclusive capabilities we claim to own. The pilot should compare the workflow against the merchant’s existing alternatives and measure both the benefit and the cost of serving it.