For the businesses that build their own
Some merchants do not want a dashboard. A marketplace paying out to hundreds of sellers, a SaaS product billing its own customers, a platform embedding accounts for the businesses it serves: all of them need the same rails, reached through code rather than a screen.
Everything the dashboard does is an API call.
What is available
Payments. Create charges, capture, refund, and read settlement. The same channels the hosted checkout uses.
Accounts. Open accounts, read balances and transactions, initiate transfers, on behalf of the businesses on a platform.
Payouts. Disburse to many recipients in one instruction, with per-recipient status rather than a single pass or fail.
Lending. Read offers and their status where a platform surfaces credit to its own merchants.
How integration goes
Sign up for a developer account and get credentials. Build against the SDKs or call the REST endpoints directly. Test in the sandbox, which issues real-shaped responses for cases that are hard to produce on demand, including declines, disputes and delayed settlement. Then swap the keys for production ones.
Webhooks
Every state change emits an event: a payment authorised, a settlement paid, a dispute opened, a payout failed. Events are signed, retried on failure, and replayable from the dashboard for a window after they fire.
Polling is supported but not expected.
One integration, several markets
The market a transaction belongs to is a parameter, not a separate integration. A platform that has integrated once can extend to another market as licensing allows, without rebuilding.
Support
Technical support is staffed by engineers rather than routed through a general queue, and integration reviews are available before go-live for platforms handling other people's money.