TransFi Payment Gateway Integration
Connect TransFi to PayLexer to accept cards, local bank rails, mobile wallets, and stablecoins in 36 currencies from a single merchant account.
TransFi is a global cross-border payment provider that accepts ordinary money and cryptocurrency through the same checkout. It gives a merchant 250+ local payment methods across 63 countries from one account, so a shopper can pay by card in Australia, by PIX in Brazil, from a mobile wallet in the Philippines, or in stablecoins such as USDC and USDT, and the merchant still sees one payment in their own currency.
- Supported Regions (Merchant Accounts): 63 countries across Latin America, Southeast Asia, Africa, the Middle East, Europe, and North America - view full list
- Supported Currencies: 36 payin currencies including AUD, BRL, EUR, PHP, SGD, USD, and ZAR - view full list
PayLexer offers TransFi at checkout only for the currencies TransFi can collect: AED, ARS, AUD, BDT, BRL, CAD, CHF, CLP, CNY, COP, CZK, EUR, GHS, HKD, IDR, JPY, KES, MXN, MYR, NGN, NOK, NZD, PEN, PHP, PKR, PLN, SEK, SGD, THB, TZS, UGX, USD, VND, XAF, ZAR, and ZMW. An order in any other currency is rejected before the shopper is sent anywhere. XOF is deliberately excluded because TransFi supports it for payouts only.
Supported Features
- Hosted payment page where the shopper chooses card, local bank rail, mobile wallet, or stablecoin
- Payments in 36 currencies across 63 countries from a single merchant account
- Automatic payer record creation, reused for every later order by the same shopper
- Signed webhook notifications that complete an order even when the shopper never returns to your store
- Optional control over which payment rail your orders use
- Per-rail amount limits checked before the shopper is sent to pay
- Separate sandbox and live credentials for safe testing
TransFi refunds cannot be issued from PayLexer. TransFi has no refund API. Its support team raises refunds from their own admin dashboard against a customer request with proof of payment, so a refund attempt in PayLexer is refused with an explanation rather than appearing to succeed. Plan for this before you enable TransFi on a store that refunds often.
TransFi cannot be used for subscriptions. Its API has no recurring-billing, plan, mandate, or saved-instrument capability, so there is nothing to charge a second time. Sell subscription products through a gateway that supports them. View all supported gateways →
Before You Start
Make sure you have:
- TransFi Account – Don't have one? Sign up for TransFi →
- PayLexer Account – Required to configure the integration. Create your account →
- A website where you want to integrate
Looking for a different payment processor? View all supported gateways →
Configuring TransFi
You need an API Username, an API Password, and a Merchant ID (MID) from TransFi for this integration.
Getting API Credentials
TransFi issues a separate username, password, and Merchant ID for sandbox and for live. The two sets are not interchangeable, so collect whichever set matches the environment you are setting up.
Create or open your TransFi account
Sign in to the TransFi dashboard. Signing up is self-service: company details, an email one-time code, a password, then multi-factor authentication with an authenticator app. You only need to complete business verification when you are ready to accept real money.

Copy your API username and password
Go to Settings → API Credentials. Copy the API username, then click Regenerate to produce the API password.

The API password is shown once, at the moment you generate it. Copy it straight into PayLexer. If you lose it you must regenerate, which invalidates the previous password and breaks any integration still using it.
Copy your Merchant ID (MID)
Copy the Merchant ID for the account. TransFi requires it on every single API call, separately from your username and password.

A valid username and password with a wrong or missing Merchant ID authenticates successfully and then fails every request. PayLexer reports
this as a distinct error naming the Merchant ID, so you are not left debugging credentials that are already correct.
Adding Credentials to PayLexer
Open PayLexer Dashboard
Log in to your PayLexer dashboard and navigate to Payment Gateways → TransFi.

Enter your credentials
Paste the API Username, API Password, and Merchant ID (MID) you copied from TransFi into the corresponding fields. The sandbox fields are labelled Sandbox API Username, Sandbox API Password, and Sandbox Merchant ID (MID).

Understanding Live/Production and Sandbox Settings:
| Environment | Purpose |
|---|---|
| Live / Production (Mandatory) | Used for real transactions. Cannot be empty, even when testing. |
| Test / Sandbox (Optional) | Used for testing only. No real money is processed. |
How PayLexer selects credentials:
- Debug/Test mode ON → Test credentials are used
- Debug/Test mode OFF → Live credentials are used
Test and save
Click Save to save your configuration and verify your credentials. Click Verify Connection to test the connection.
How the Payment Method Is Chosen
You do not configure this. TransFi requires every order to name a payment type, and the rails your account has enabled differ by currency, so PayLexer reads the rails your account actually has for the order currency and picks one.
The order it prefers is card, then bank transfer, then local wallet:
- Card first because it settles immediately and is what most shoppers expect.
- Bank transfer next. It can take hours to settle, but it works for anyone paying in that currency.
- Local wallet last. TransFi's payment-method list does not say which country a wallet belongs to, so a wallet can be one your shopper has no way to open — a slow rail the shopper can use beats a fast one they cannot.
When your account has only one rail for a currency, there is nothing to choose.
PayLexer sends the payment type to TransFi, and TransFi's payment page then shows your shopper the enabled methods of that type. A shopper on a bank transfer order therefore still sees every bank rail your account offers for that currency.
Configuring Webhooks (Mandatory)
Webhooks enable real-time payment updates and significantly improve reliability.
Benefits of Webhooks:
- Instant payment status updates
- Orders completed even when the shopper closes their browser
- Accurate failure, expiry, and compliance-hold records
TransFi holds one webhook address per account rather than accepting one per payment, so you paste the URL into your TransFi dashboard once.
Copy your PayLexer webhook URL
In your PayLexer dashboard, go to Payment Gateways → TransFi and copy the generated Webhook URL.
Paste it into TransFi
In your TransFi dashboard, go to Settings → Integration and paste the URL as your webhook endpoint.

Copy the webhook secret back to PayLexer
TransFi gives you a signing secret on the same page, with a button to regenerate it. Copy it into the Webhook Secret field in PayLexer for the environment you are configuring, then click Save.

The secret is stored per environment. A sandbox secret pasted into the live field, or the reverse, makes PayLexer reject every notification as unsigned, and orders stay pending with no visible error at TransFi's end.
Until the webhook URL and secret are both in place, orders complete only when the shopper returns to your store, which means a shopper who pays by bank transfer and closes their browser leaves an order unpaid. This is why the webhook setup is mandatory rather than optional.
Returning from TransFi's payment page is never treated as proof of payment. TransFi returns the shopper the moment they submit, which for a bank transfer is well before the money arrives, so PayLexer confirms the outcome with TransFi first. A payment that is still in flight, or one held for TransFi's compliance review, returns the shopper to your checkout page and leaves the order open until the funds actually settle.
Integrate TransFi to Your Website
If you have already added and configured your site, you can enable TransFi in your existing setup.
Go to Websites
Navigate to Websites in your PayLexer dashboard.
Edit your website
Click the Edit Icon of your added website.

Enable TransFi
Click the checkbox to enable TransFi for the website.

If you haven't added a website yet, Continue to Add Your Website →
What TransFi Requires at Checkout
TransFi requires a verified email or phone number and a complete payer record before issuing a payment URL. Incomplete details are rejected. This is the single most common reason a TransFi checkout fails before the shopper ever sees a payment page, so it is worth getting right before you go live.
Make billing phone and billing address required fields at your checkout. If either is missing, the order fails at creation with a message naming the field.
The fields TransFi validates
| Field | What "valid" means |
|---|---|
| Country | Must be a country TransFi serves — see TransFi's supported countries. This is the shopper's billing country, not where your business is. An unsupported country is refused outright and no configuration on your side can change it |
| Street address | Must be a real street that TransFi can resolve for the city and postcode given. This is the one that catches people out — see the callout below |
| City | The real city for that street and postcode |
| Postal code | A real postcode for that city. Supplying one is what makes TransFi look the street up |
| Phone | Must be a valid number for the billing country. Either give it in international form (+61 …) or make sure the billing country is set, because TransFi needs a dialling code and derives it from the country when the number has no prefix |
| State / province | TransFi does not currently check this, but keep it correct anyway — it appears on your own records and other gateways do check it |
A worked example — Australia
These five values are consistent with each other, which is the part that matters:
Street address : 200 Bourke Street
City : Melbourne
State : VIC
Postal code : 3000
Country : AU
Phone : +61 491 570 006
Change the country and every other field has to change with it. A Philippine order needs
a Philippine street, city, postcode and a +63 number — you cannot keep an Australian
address and only swap the currency.
The postcode triggers a street lookup. When a postcode is present, TransFi resolves the street against it and refuses an address it cannot find. Placeholder checkout data is the usual culprit: a street that does not exist for that city and postcode.
Mixing two cities is the most common version of this. 200 Bourke Street with Sydney
and postcode 3000 is refused, because Bourke Street and 3000 are Melbourne while Sydney
is 2000. The street, city and postcode must describe one real place.
Payer verification
TransFi verifies the payer's email or phone as part of its own compliance checks. A payer record created fresh from your checkout data starts out unverified, and TransFi may ask the shopper to confirm a code on its payment page before the payment can complete.
This does not block order creation — the order is created and the shopper reaches the payment page either way. It affects whether the payment can be completed, so:
- Collect a phone number and email the shopper can actually receive a message on. A placeholder or mistyped address means the shopper cannot get past the verification step
- Returning shoppers are matched to their existing TransFi payer by email, so a shopper who verified once does not verify again
- Some currencies add their own identity step on TransFi's page beyond this. A Mexican SPEI payment, for example, asks the shopper for a CURP or RFC document number, which is issued by the Mexican government and must be in that exact format
Both checks belong to TransFi, not PayLexer, and both happen on TransFi's own payment page after the redirect. PayLexer cannot pre-fill or skip them.
Troubleshooting
Best Practices
- Test in sandbox before enabling production, using your sandbox username, password, and Merchant ID
- Set up the webhook URL and secret before your first live payment, not after. Without them, orders complete only when the shopper returns
- Make phone number and billing address required at checkout, because TransFi requires both on every payer record
- Confirm which rails your account has enabled for each currency you sell in before going live, so you are not surprised by a payment method your shoppers cannot use
- Agree a refund process with TransFi support before you launch, since refunds cannot be issued from PayLexer
- Reconcile PayLexer Dashboard → Orders against your TransFi dashboard regularly
FAQs
Still Have Questions?
- TransFi Support: TransFi Documentation
- PayLexer Support: Contact Support