How it works
We're the experience. You keep the rails.
PayMongo channels are the surface your customer pays on. The processing underneath stays with the provider you already contract with — and this page is the map of exactly where the line sits.
Four layers, and we are one of them
Read it left to right. Only the shaded layer is ours.
Your customer
On a phone, at a table, in a chat thread
- PayMongo
PayMongo channel
The page, the states, the retries, the branding
Your processor
Authorisation, the methods, the money
Your acquirer or bank
Where it lands, on the terms you already hold
One layer changes. The three around it do not.
Who owns what
No overlap, and nothing left ambiguous. If it touches the money, it is not ours.
What PayMongo provides
- The interface
The page, sheet or menu your customer actually uses, on your brand rather than ours.
- Payment states
Pending, authorised, failed, expired — surfaced to the customer in language they understand and to your systems as webhooks.
- Validation and retries
Field validation before submission, and a sane path back when a transaction is declined.
- Mobile flows
The small-screen version, designed first rather than adapted.
- Branding
Logo, colour, type, copy and language, per market if you need it.
- Hosting
We run and secure the surface. PCI DSS Level 1 applies to this layer.
What stays yours
- Processing
Your processor authorises every transaction, under your existing contract.
- The funds
Money never rests with us. It goes where it goes today.
- Settlement
Your processor settles to your account on your existing terms. We are not in that path and could not be.
- Reconciliation
Your reports, your ledger, your close. Our webhooks feed them; they do not replace them.
- Merchant of record
You remain the merchant of record. We do not stand between you and your customer.
- Disputes
Chargebacks and refunds stay with your processor and in the tooling you use for them now.
What integration actually involves
Three steps, and none of them ask you to change provider.
Connect your processor credentials
You supply the keys for the provider you already use. We use them to render the methods your contract covers — nothing more.
Configure the channel
Branding, fields, languages and currencies. Configuration, not a build.
Publish
Point your existing create-payment call at the channel and go live. Your processor sees the same traffic it always did.
PLACEHOLDER: integration snippet — must be taken from docs.paymongo.com once the global endpoint is published, never written to look plausible
What we see, what we store, what we never touch
What we see
The transaction amount, currency and reference you send us
Which method the customer chose
The state your processor returns
What we store
Your channel configuration and branding
A record of each transaction's states, so your systems can be re-notified
The fields you chose to collect
What we never touch
Card numbers — they go to your processor, not through us
Your customers' money, at any point
Your processor contract, pricing or scheme relationships
Where this works today
PLACEHOLDER: regional availability — the honest list, including the markets we cannot serve yet and why
The hard questions
The ones a serious evaluator asks in the first call, answered here instead.
If your processor's own checkout fits your product, use it — you don't need us. The channel layer earns its place when the surface is the constraint: their hosted page can't carry your brand, a market needs a flow it won't render, or you sell through surfaces they don't make — QR ordering at a table, a storefront generated from a description, a link created per invoice. Their page ties the experience to the rail. Ours unties it.
Orchestration platforms decide which processor a transaction routes to — infrastructure, sold to payments teams. We build what the customer touches — the checkout, the link, the menu, the store — sold to whoever owns conversion. No routing, no traffic through us, no processor decisions taken out of your hands. If you already run an orchestrator, the channel layer sits in front of it exactly as it sits in front of a processor.
The surface stays. Your customers keep the same checkout, the same links, the same menus; the credentials underneath change. That is the point of separating the experience from the rail — the processor becomes a decision you can revisit without a front-end rebuild.
You pay your processor for processing. You pay us for the surface — the thing you would otherwise staff a front-end team to build and keep rebuilding. Compare our fee to that headcount, not to your processing rate. The two charges never overlap.
The honest answer: the page we render is what's down — your rails and your processor are unaffected, but a customer on that surface can't pay until it's back. We publish status openly and design every channel to fail loudly, not silently. PLACEHOLDER: uptime figure and support SLA — engineering's measured number, not a marketing one.
Card data never touches us — it flows to your processor. What we hold is the surface layer: page configuration, order and session records. PLACEHOLDER: hosting regions and data residency — the infrastructure answer, stated once it is confirmed.
Tell us your processor.
The first call is a straight answer about whether the channel layer fits what you already run.