Skip to main content

​
The problem this solves

Every TagadaPay account (TPA) has a default acquiring route: the acquiring account its charges go through, which settles in one currency (the TPA’s home currency, chosen at provisioning). A charge in any other currency is converted at settlement — you sell in EUR, settle in USD, then convert back to EUR at payout: two FX conversions you didn’t ask for. Acquiring routes remove that. You enable one route per charge currency; from the next charge on, charges in that currency go through an acquiring account that settles natively in it:
Your balance then simply holds one bucket per currency (see balance.retrieve()), and each bucket sweeps to a bank account in its own currency.
Nothing changes for the buyer. The card is charged in the presentment currency either way; routes only change the currency your funds settle and stay in. Statement descriptor, 3DS behaviour and approval rates are unaffected — the route clones your store identity.

​
List your routes

REST: GET https://api.tagadapay.io/api/tagadapay/v1/partner/tpas/:id/routes

​
Enable a route

REST: POST https://api.tagadapay.io/api/tagadapay/v1/partner/tpas/:id/routes with body { "currency": "EUR" }. What the call does, in one shot:
  1. Picks the acquiring account that settles the currency natively.
  2. Clones your store onto it (same statement descriptor, address, phone) and activates the core card schemes (Visa, Mastercard, Amex, Discover).
  3. Persists the route — the charge router uses it automatically for every subsequent charge in that currency. No change to your payments.process() calls.
Rules to know:
  • Idempotent. Re-enabling an existing currency returns the route with created: false. Enabling the TPA’s home currency is a no-op (the default route already settles it).
  • New charges only. Refunds, captures and voids of a past charge always follow the route the original payment took — Adyen requires modifications on the same acquiring account.
  • Unknown currency → 422 no_merchant_account_for_currency. No acquiring account settles that currency yet; charges keep flowing through the default route (converted at settlement, like today). Ask your account manager which currencies are available.
  • MoR sub-merchants: enable the route per child TPA (each child owns its own store). Funds still settle into the root’s balance — in the route’s currency.
  • The TPA must be fully provisioned (an active default route) — otherwise 409 not_provisioned.

​
Payouts per currency

Each settled currency accumulates in its own balance bucket. To receive it without conversion, register a bank account in that currency — otherwise the sweep converts at payout:
The two calls are the two halves of the same loop: enableRoute() controls the currency your funds settle and stay in, createBankAccount() controls the account each bucket pays out to. tpas.payout() and the daily sweeps handle multi-currency balances bucket by bucket. See Payouts, balances & fees for the bank-account rules (verification, one per currency, MoR roots).
One TPA, many currencies. Do NOT create one TPA per settlement currency — a TPA is a legal entity (one KYB, one balance, one set of keys). Adding a currency to an existing TPA is exactly the two calls above; a new TPA is only ever justified by a different legal entity.