Top Pay

Brazil · India

Collect in reais and rupees.
Settle in dollars.

Your customers pay the way they already pay — a PIX QR code in Brazil, a UPI intent in India — from their own bank app, in seconds, at three in the morning on a Sunday. You get one API, one ledger and one reconciliation.

See the integration Request access
Country
Brazil · BR
Rail
PIX
Currency
BRL · 2 dp
Collect
Live
Pay out
Live
Opening hours
24 / 7 / 365
Confirmed by
End-to-end ID
Settled in
USDT

What is live

Two countries, done properly, rather than forty on a map.

Every corridor below is a rail we clear on, not a logo we have a meeting with. Where something does not exist, it says so.

Country Rail Currency Collect Pay out Method code
BR Brazil PIX BRL Live Live pix
IN India UPI INR Live Not offered upi

India is collection only. We would rather refuse a payout than accept one and discover at settlement that we cannot make it — so a payout request for IN is rejected when you send it, not hours later.

How a payment moves

Five steps, and you are told the truth at each one.

  1. You ask for a payment

    One signed POST /v1/payments carrying your own reference, the country, the rail and an amount in integer minor units. Send the same reference twice and you get the same payment back, not a second one.

  2. We route it and hand back instructions

    A PIX copy-and-paste code for Brazil, a UPI intent for India. Show it, or send your customer to the hosted page — whichever suits your checkout.

  3. Your customer pays from their own bank app

    No card, no redirect to a form they distrust, no 3-D Secure step that loses a fifth of them. They approve it where they already keep their money.

  4. The rail confirms, with a number you can take to a bank

    An end-to-end ID in Brazil, a UTR in India. We store it against the transaction and hand it back on every read, because it is what settles an argument with a customer who says they paid.

  5. We post it and tell you

    A signed webhook, retried until you acknowledge it, and a double-entry journal written the moment the money moved. The webhook is a convenience; the ledger is the record.

Integrate

One request out, one webhook back.

The whole surface is seven endpoints. Here is the only one most integrations ever call, and the message it eventually produces.

Create a payment 
POST /v1/payments
X-PSP-Key-Id:     key_live_7f2c…
X-PSP-Timestamp:  1758657600
X-PSP-Signature:  2f9a…  ← HMAC of the raw body

{
  "reference":     "order-84412",
  "country":       "BR",
  "method":        "pix",
  "currency":      "BRL",
  "amount_minor":  125000,      ← R$ 1,250.00
  "customer_ref":  "cust_9931"
}
…and the webhook that follows 
{
  "id":            "TXN_01JBQ7F3K2WZ",
  "reference":     "order-84412",
  "direction":     "payin",
  "status":        "paid",
  "country":       "BR",
  "method":        "pix",
  "currency":      "BRL",
  "amount_minor":  125000,
  "utr":           "E1803625820250923…",
  "created_at":    "2026-09-23T18:04:11Z"
}

Amounts are integers. Always.

We never accept a decimal amount. "10.00" invites a float somewhere upstream, and by the time it reaches us the rounding has already happened out of our sight. Type an amount and see what you would actually send.

Underneath

A gateway you can audit, not just call.

Double-entry, append-only

Every movement is a journal whose entries sum to zero in each currency, enforced by the database rather than by good intentions. Nothing is ever edited; a correction is its own entry.

Signed in both directions

Your requests are signed and timestamped, ours are signed and retried. A replayed request is refused, not quietly executed a second time.

Idempotent by design

Your reference is the idempotency key. A lost response, a timeout, a retry from a queue you did not write — none of them create a second payment.

Reconciliation you can see

Positions per currency, per rail, in the console, against the settlement file. When a number disagrees, you find out from us first.

More than one provider

Each corridor can run on more than one underlying provider. If one degrades, the next takes the traffic — and the ledger reads the same either way.

An audit log that resists you

Operator actions are hash-chained, so a tampered history does not verify. Two-factor is mandatory for every operator, not an option in a settings page.

Tell us what you are collecting.

Corridor, volume, currency. We will tell you plainly whether we are the right fit — including when we are not.

[email protected]