Integrating Payment Gateways for a Visa Agency

The wrong way to choose a payment gateway is to compare feature tables. The right way is to look at where your applicants live and ask how people in that market actually pay for things online.

That answer varies more than most agency owners expect. Card penetration is high in some markets and low in others. Bank transfer is the default in parts of Europe and much of the Gulf. Wallet and local payment methods dominate in several large source markets, and a checkout offering only international cards will simply fail there — not with an error message, but with an applicant who quietly leaves.

So the first task is a short table: your top five source markets by application volume, the currency each expects, and the one or two payment methods that are normal there. Then find the gateway that covers the most of that table. An agency processing mostly from India and Nigeria has different requirements from one serving corporate clients in the UK, and pretending otherwise costs you conversions you never see.

Second task: check acceptance, not just availability. A gateway may technically support a country while its risk rules decline a high share of cards from it. If you can, run a small live test from each major market before committing — a handful of real transactions tells you more than any documentation. For the broader landscape of what gateways suit visa work, our payment processing guide covers the main options.

*Multi-gateway* sounds like a feature and is really an operating decision. It means that at checkout, the applicant is offered more than one way to pay, and that whichever they pick, your back office sees one consistent record.

The second half is the hard half. Two gateways means two dashboards, two payout schedules, two fee structures, two refund flows and two sets of dispute rules. If those never converge into a single view of *this application, this amount, this state*, you have not added a gateway — you have added a second bookkeeping system.

The workable pattern is that your platform owns the order and the gateways are interchangeable ways to settle it. The order carries the reference, the amount, the currency, the fee breakdown and the status. The gateway reports back success, failure or refund against that reference. Anyvisa runs this way across Stripe, PayPal and a bank gateway, letting a varied client base pay how they prefer while the admin team works from one unified transaction view.

Be disciplined about how many you add. Every gateway you support is one more thing to reconcile monthly, one more integration to keep alive, and one more place a refund can go wrong. Add the second because a real market needs it. Do not add the third because it appeared in a comparison article. If you do run several, the integrations layer is what keeps them from fragmenting your books.

Multi-currency has three separate decisions inside it, and conflating them is the source of most currency-related support tickets.

Display currency is what the applicant sees on the page. It should be the currency they think in. Someone in Turkey comparing agencies is not converting from GBP in their head; they are moving on to the site that showed a number they recognise.

Settlement currency is what lands in your bank account. Most agencies settle in one home currency regardless of what was displayed, because managing balances in eight currencies is an accounting job nobody wants.

The quoted rate sits between them, and it needs a rule. Lock the exchange rate at the moment the order is created and hold it for the life of that order. If rates move between the applicant seeing a price and paying it, the price they agreed to must not change. Refresh your rates on a schedule — daily is fine for most agencies — and build a small margin into the rate rather than adding a surprise conversion line at checkout.

One detail worth knowing: displaying a price in local currency does not always mean the card is charged in it. Depending on the gateway, the applicant's bank may perform the conversion, apply its own rate, and produce a statement figure slightly different from your total. Say so in a short line near the total. It costs nothing and prevents a category of *you charged me the wrong amount* messages. Our answer on collecting visa payments online covers the setup end to end.

Visa pricing has a structure that most industries do not: part of what you collect is not yours. The embassy, consulate or authority sets a fee, and you are collecting it on the applicant's behalf. How you handle that is the clearest signal of how your agency operates.

The honest default is to pass it through at cost and show it as its own line. Government fee, service fee, add-ons, total. The applicant can see exactly what they are paying you for, which is the single most effective way to defuse the hidden-fee suspicion that hangs over this industry. The government fee versus service fee distinction is worth explaining on your site in plain language too, because many first-time applicants do not know it exists.

There are real complications. Some fees are per applicant and some are per application, which matters enormously for family cases. Some are collected by you and paid onward; others the applicant pays directly at a visa application centre or online, and your platform needs to record that it was paid without having taken the money. Fees like the MRV fee or the immigration health surcharge follow their own rules, and rates change — treat every published figure as *current, verify with the official source*.

Build fee changes in as routine maintenance, not as an incident. Whoever owns pricing should have a monthly slot to check the official fee schedules for your top visa types and update them in one place, so the checkout, the invoice and the visa page all move together. Agencies that store fees in three places always end up quoting one that is out of date.

Payment integrations fail in predictable ways. Working through a short checklist before launch removes almost all of them.

Test the failure paths, not just the happy one. A declined card, an abandoned 3D Secure challenge, a browser closed mid-payment, a duplicate submission from an impatient double-click. Each should leave the application in a sane state that a staff member can understand at a glance. Confirm webhooks are the source of truth. The customer's browser returning to a success page is not proof of payment; the gateway's server-to-server notification is. Systems that mark orders paid on redirect will eventually mark unpaid orders paid. Check idempotency, because if the same notification arrives twice — and it will — the applicant must not be charged twice or the order marked paid twice.

Verify the receipt. It should be generated automatically, sent immediately, stored on the client record, and contain the fee breakdown, the payment method and a reference. B2B clients sending staff on business trips need a proper invoice for their accounts payable, not a payment confirmation email. Decide the timeout policy as well: how long does an unpaid order stay open before it expires, and does an expiry release anything? Without a rule, your pipeline slowly fills with half-finished orders that distort every report you run.

Finally, test on a phone in a poor connection, because that is the real environment for a large share of applicants. The e-commerce layer of a purpose-built platform handles most of this by default, which is much of the argument for not building checkout yourself — see should I build or buy visa agency software.

Reconciliation is where payment integrations quietly become an operational burden. The bank statement shows a payout. The payout is a batch of transactions, net of fees, possibly across currencies, possibly including refunds. Somebody has to tie that back to individual applications.

The rule that makes this tractable is to attach your own application reference to every payment at creation. Not the applicant's name, not the amount — a reference that exists in your system and travels with the transaction into the gateway. From there, matching is mechanical. Without it, you are reconciling by name and amount, which breaks the first time a father pays for three children's applications in one transaction or two clients pay the same standard fee on the same day.

Expect three recurring exception types and design for them rather than treating each as a surprise. Partial payments, where an applicant pays the service fee now and the government fee later. Third-party payers, where the name on the card does not match the applicant — extremely common in family and corporate work. Gateway fees, which mean the amount received never equals the amount charged, so your revenue figure and your bank figure will differ by design.

Run reconciliation weekly rather than monthly. A week of exceptions is a short list somebody can clear in half an hour with the details still fresh. A month of exceptions is a project that gets postponed. If your reconciliation currently lives in a spreadsheet you rebuild each month, that is a strong signal to look at what a visa CRM does and at the difference from running on spreadsheets.

Refunds in visa work are not a payments problem first. They are a policy problem, and the payments part only gets easy once the policy is decided.

Write the policy before you integrate. What happens if the applicant withdraws before you have done any work. After you have prepared the file but before lodging. After lodging. After a refusal. Government fees are typically non-refundable once an application is lodged, and that is outside your control — but whether you return part of your service fee after a refusal is entirely your decision, and applicants will ask. A clear policy published on your site, applied consistently, prevents most disputes from starting.

Once the policy exists, encode it. A refund should be issued through the original payment method, generate a credit note automatically, update the application state, and be visible on the client record. Manual refunds made from a gateway dashboard without a matching entry in your system are how books stop balancing.

Chargebacks deserve their own preparation. A visa refusal is not a service failure, but a frustrated applicant may present it to their bank as one. Your defence is evidence: the terms they accepted at checkout, timestamped records of documents requested and received, the submission confirmation, and the communication history. Systems that keep the full case history in one place make responding to a chargeback a twenty-minute job instead of a day of searching inboxes.

One last honest note. Refund volume is usually a symptom, not a cost of doing business. If a particular visa type generates repeated refunds, look upstream at whether the page set expectations badly or whether you are accepting cases you should decline.

There are three good reasons to add a gateway. A market you actively sell into cannot pay through what you have. A client segment requires a specific method — corporate clients who must pay through their company's banking relationship are the common case. Or your current provider's decline rate for a major market is measurably hurting conversion.

There are several bad reasons, and they all look like the good ones at first. Slightly lower headline fees, which usually vanish once cross-border and currency charges are counted. A feature you might use later. A recommendation from an agency operating in a completely different market. In each case, the ongoing cost of a second reconciliation and refund path outweighs the benefit.

When you do add one, decide the routing rule explicitly. Does the applicant choose at checkout, or does the platform pick based on country or currency? Choice builds trust — some applicants strongly prefer paying through a wallet rather than entering card details on an unfamiliar site — but too many options at checkout also cause hesitation. Two or three clearly labelled choices is usually the sweet spot.

And measure afterwards. Track authorisation rate, completion rate and support contacts per gateway. If the new one is not carrying meaningful volume after a quarter, remove it rather than maintaining it out of politeness. Feed those numbers into the same weekly view you use for the rest of the business — see the reporting dashboard an owner should read weekly.

If you would rather not own this plumbing at all, that is a fair position. VisaCRM is a productized service — the payment layer, checkout, invoicing and reconciliation are built, branded and run for your agency, which owns the result. It does not file government forms or give legal advice. Tell us which markets you sell into and we will tell you honestly what the payment setup would look like.