Key concepts

The platform model

PayMongo Capital is a platform. PayMongo itself is not the lender. Partner lenders — regulated banks, rural banks, SEC-registered financing companies, and licensed fintech lenders — onboard onto the platform, access consented merchant data, create offers, fund approved loans, and receive repayment. PayMongo provides the rails: merchant reach, underwriting-grade data, offer distribution, automated repayment collection, and compliance infrastructure.

This has three implications you should internalize before reading further:

  • There are always three parties in any Capital transaction: the merchant (borrower), the lender (partner institution), and PayMongo (the platform).
  • The contract is between merchant and lender. PayMongo facilitates but is not a party to the loan.
  • Lender diversity matters. Different lenders set different eligibility criteria, offer sizes, fee structures, and sweep rates. Merchants may see multiple offers, or none, depending on their profile and the lenders active in their segment.

The Capital loan lifecycle

The Capital lifecycle spans four objects. Each has its own states; together they trace the full journey from offer to repayment.

Offer states — lender-managed product templates:

StateTriggered ByMeaning
activeLenderOffer is live; eligible accounts can be invited to apply.
inactiveLenderOffer temporarily paused; accounts cannot apply.
deletedLenderOffer permanently removed. Terminal state.

Application states:

StateTriggered byMeaning
submittedAccountApplication submitted; awaiting lender review.
under_reviewLenderLender is actively reviewing the application.
approvedLenderApplication approved; a contract and loan are created and disbursement is triggered.
rejectedLenderApplication declined. Terminal state.

Loan and Contract states — created on application approval:

ObjectStateTriggered ByMeaning
LoanactiveSystemLoan disbursed; repayments are being collected.
LoanrepaidSystemAll outstanding amounts cleared; loan closed.
ContractactiveSystemOne or more loans under the contract are active.
ContractcompletedSystemAll loans under the contract have been fully repaid.

Consent and data access

Merchants on PayMongo do not automatically share data with lenders. When a lender creates an offer targeting a merchant, the merchant sees the offer in their Dashboard along with a consent screen explaining:

  • Which lender is making the offer.
  • What data PayMongo will share with the lender on acceptance (transaction history window, wallet balance, settlement cadence).
  • The full repayment terms.

Acceptance of the offer is acceptance of the data-sharing scope for that loan. Before acceptance, lenders only see aggregated, anonymized eligibility signals — not the merchant's identity.

Glossary (quick reference)

Every loan on Capital today is revenue-based. Instead of a fixed monthly payment over a fixed term, the merchant repays out of a percentage of their daily settled sales. Because repayment is a percentage of sales, slow days cost the merchant nothing extra and fast days finish the loan sooner. This is the core risk-sharing property of revenue-based financing.

The following terms recur throughout this section:

  • Merchant / Account — a business with a verified PayMongo account. The borrower on a Capital loan. The API refers to this entity as an account; the Dashboard and this documentation use merchant as the human-facing term.
  • Lender — a regulated partner institution that has passed Capital onboarding and is funding loans to PayMongo merchants.
  • Offer — a product template created by a lender that defines the loan parameters (type, amount range, fees, repayment rate, term range) under which merchants can apply. Lenders invite specific accounts to apply for an offer.
  • Application — a merchant's request for a loan under a specific offer. Carries the chosen principal amount, term, purpose, and supporting documents. Moves through submitted → under_review → approved / rejected.
  • Contract — created on application approval. The legal loan agreement binding the lender and merchant. A contract may have one or more loans.
  • Loan — the active financing instrument under a contract. Tracks outstanding_principal_amount, outstanding_interest_amount, and outstanding_dst_amount separately. Transitions from active to repaid when all balances reach zero.
  • Principal amount — the cash the lender approves and disburses to the merchant's PayMongo wallet on loan creation.
  • Interest fee (interest_fee / interest_fee_type) — a fee configured at the offer level. Can be a fixed centavo amount (fixed) or basis points of the principal (bps). There is no compounding; the fee is computed at loan creation and does not change based on how quickly or slowly the merchant repays.
  • DST — Documentary Stamp Tax, a Philippine government levy on lending instruments, required under Philippine law for lending instruments. Calculated by the platform at loan creation and tracked separately as outstanding_dst_amount on the loan.
  • Total repayment — principal + interest + DST. Tracked as three separate outstanding amounts (outstanding_principal_amount, outstanding_interest_amount, outstanding_dst_amount) on the loan object. Repayments are applied in that priority order.
  • Repayment rate (repayment_rate / repayment_rate_type) — the percentage (or fixed amount) of each day's settled transactions collected as a repayment. Configured on the offer; fixed for the life of the loan.
  • Daily sweep — the automated end-of-day collection from the merchant's PayMongo wallet, calculated as daily_settled_amount × repayment_rate, capped at the outstanding balance.
  • Expected term (term / term_type) — the loan term agreed at application and fixed on approval. Expressed in weeks or months. Actual repayment speed varies with sales.
  • Settlement — the daily settled transaction proceeds landing in a merchant's PayMongo wallet. The base for sweep calculation.
  • Wallet — the merchant's PHP fiat wallet on PayMongo. Source of repayment debits.