Gateway API — Tranzify

One request, every rail

A merchant creates a payment with amount, currency, method and customer; Tranzify decides the route, calls the provider and reports back. Cards, Apple Pay and Google Pay, Open Banking, PIX, UPI, QRIS, bank transfers, vouchers, crypto and payouts share the same request and the same statuses. The merchant’s code does not know which provider processed the payment and does not need to: when the client adds an acquirer or a local method, the merchant’s integration stays as it is.

The answer to the request is an action: redirect the payer to a page, show a QR code, show bank details with a reference, wait for a wallet’s confirmation, or nothing at all when a token was charged server-to-server. The final state arrives by a signed webhook and can be read at any time from the payment’s resource.

What the API gives

Hosted checkout in 29 languages under the client’s brand, or server-to-server for merchants with their own PCI scope.
Tokens for recurring and one-click payments; merchant-initiated charges without a CVV where the provider allows it, with the scheme’s indicators set by the platform.
Payouts to cards, bank accounts, wallets and PIX keys through the same contract; single or in a file.
Refunds, partial and full, with the status history of every payment and every refund.
Signed webhooks with retries, a resend button in the back office and the full trace of every delivery.
Sandbox with the same contract as production, for the merchant’s tests before the switch.
Keys and secrets per merchant, separate for sandbox and production.

The payment’s life

Step	What happens	What the merchant sees
Create	The request is validated and the payment stored with its reference	The payment’s reference and the action to take
Route	The network’s flow chooses the terminal; limits and restrictions are applied	Nothing: routing is the client’s configuration
Process	The provider is called; on a decline or a timeout the cascade calls the next terminal	A redirect, a QR code, bank details, or an immediate result
Confirm	The provider’s callback is verified and mapped to the platform’s status	A signed webhook; the status on the payment’s resource
Settle	Fees, balances and reserves are written to the ledger	Balances and settlements in the merchant cabinet
Change	A refund, a chargeback, a late callback	A webhook per event, in the same format

Every step is in the payment’s journal for five years, with the raw request and answer of every provider call, so support can open the trace of any payment a merchant asks about.

Integration step by step

The sandbox has the same contract as production. A merchant’s developer creates a payment, follows the action, receives the webhook and checks the signature, and runs the merchant’s own test suite against it. When the tests pass, production keys are issued and the merchant switches when it chooses; the hosted checkout needs no development at all.

Migrating merchants

A merchant moves to Tranzify one at a time: the hosted checkout by a link, an API integration through the sandbox with its own test suite, then production keys. The client keeps both platforms side by side until the last merchant has moved, and the payment history of the old platform is imported for reports. The migration page describes the path step by step.

One request, every event

A merchant sends one request; the platform routes, cascades, journals and calls the webhook. The events on the right are what the trace of that payment shows in the back office.

POST /v1/payments
Authorization: Bearer sk_live_…
Idempotency-Key: 7f0e7a1c

{
  "amount": 249.00,
  "currency": "BRL",
  "method": "pix",
  "customer": { "country": "BR", "email": "ana@example.com" },
  "return_url": "https://shop.example/thanks",
  "webhook_url": "https://shop.example/hooks/tranzify"
}

Payment eventslive

0 msPOST /v1/payments → 201 · id tz_8f3a…c12 · status routing
4 msrouting.matched · flow v14 · group "LATAM · PIX"
322 msprovider.attempt · EBANX · pix-01 · declined · 05 do not honour
324 msrouting.cascade · next terminal by priority and weight
734 msprovider.attempt · dLocal · pix-02 · approved
774 mswebhook.delivered · 200 · signature ok
775 msjournal.written · 5 years · trace tz_8f3a…c12

Frequently asked questions

Is the API the same for every payment method?+

Yes. A payment is created with the same request whatever the method; the response tells the merchant whether to redirect the payer, show a QR code or wait for a bank transfer.

What about merchants already integrated with another platform?+

Merchants on the hosted checkout change a link; API merchants map their flow to the Tranzify API in the sandbox — create a payment, get an action, receive a signed webhook — then switch keys one by one while both platforms run side by side.

How are webhooks secured?+

Every webhook is signed with the merchant’s secret and retried on a schedule until the merchant answers 2xx; every attempt is in the journal and can be resent from the back office.

Does the API support recurring payments?+

Yes. A first payment with consent returns a token; later charges reference the token, without the card number and, where the provider allows it, without a CVV, under the scheme’s rules for merchant-initiated transactions.

How are API keys managed?+

Per merchant, in the merchant cabinet: keys for the sandbox and production and a secret for webhook signatures; every request is in the journal with the key that made it.

What is the sandbox for?+

A test environment with the same contract as production, where a merchant’s developer creates payments, follows the actions and receives the webhooks before production keys are issued.

Gateway API: one REST contract for cards, local methods, Open Banking, crypto and payouts