Documentation
Take your first payment.
Everything below is the real contract: the routes, the statuses, the failure codes, and the rules a correct integration follows.
Your first call
curl https://api.zintle.io/v1/payment_intents \
-H "Authorization: Bearer zk_sk_test_4f2a9c1e8b7d6053" \
-H "Idempotency-Key: 9f2c1e44-7b21-4c0e-93a1-2f7c8d5e1a0b" \
-H "Content-Type: application/json" \
-d '{
"amount": "500000",
"currency": "XAF",
"country": "CM",
"methodType": "MOBILE_MONEY",
"reference": "order-4471",
"customer": "cus_01JAY3M8QK2W7ZB5XF4TC6VD"
}'Everything else
Quickstart
Four steps from an empty project to a payment you can watch resolve.
Authentication
Every request carries a bearer token. Which token you use decides what it may do — and which environment it touches.
Hosted checkout
Send the customer to a Zintle page — or embed it in yours — that offers every method that can take the payment: mobile money, card, PayPal. No payment UI to build.
The payment flow
One instruction, one or more attempts. Understanding that split is most of what makes the rest of the API predictable.
Testing
Every branch of your integration is reachable in test mode, including the three failure modes that cause real double charges.
Webhooks
Events are written to an outbox in the same database transaction as the change that caused them, then delivered with retries. That is what makes "we sent it" and "it happened" the same claim.
Failure codes
Every provider's own error vocabulary is mapped onto this list, so your retry logic is written once. Whether a code is worth retrying is part of the contract, not a guess.
Conventions
Five rules that hold everywhere in the API. Reading them once is cheaper than discovering the fourth one in production.