Get started
How MintCash works
A short tour of the orchestration model — what happens between your "charge customer" call and the money landing in your account.
MintCash is a payment orchestration layer. You integrate with one API; we route every transaction through the best available provider for that merchant, geography, and card type. If a provider declines, fails, or times out, we can cascade the same charge to the next one — without your code knowing.
The path of a payment
Rendering diagram…
- You make one call.
POST /paymentswith an amount, currency, and either a card token or the customer's details for the hosted payment page. - MintCash picks a provider. The routing engine evaluates your merchant's rules — geography, card type, success history, fees — and selects the best fit.
- The provider charges the card. MintCash speaks the provider's dialect. You don't care which one ran the transaction.
- You get the payment confirmation. A message is sent asynchronously over a signed webhook when the final state lands.
What changes vs. integrating one PSP
| Concern | One-PSP integration | MintCash |
|---|---|---|
| Adding a provider | Re-integrate everything | We add an adapter; you change nothing |
| Routing logic | Hard-coded in your app | Stored per-merchant, evaluated server-side |
| Retries on decline | You re-call the same PSP and hope | Cascading retry across providers |
| Reconciliation | One reconciliation per PSP | One audit trail, one payment record per charge |
| Webhook shapes | One per PSP, you normalize | One canonical envelope, signed by us |