Taking money online, without losing the booking
Putting a card form on a page takes a few days. Getting a bank and a gateway to approve a travel merchant, and building a checkout that survives deposits, refunds and disputes that arrive nine months later, is the actual project.
Two different problems that look like one
Operators usually ask for "online payment" as a single item. It is two. Taking money from a buyer who holds a Vietnamese bank card and taking money from a buyer whose card was issued in Germany are separate products, with separate contracts, separate approval paths and separate failure modes.
Most Vietnamese travel businesses need both, but not on the same day. Which one you start with depends on who is actually buying from you this season, not on which one sounds more ambitious.
| Domestic gateway | International cards | |
|---|---|---|
| What it accepts | Local bank cards, QR transfer, domestic wallets | Visa, Mastercard, Amex issued abroad, some wallets |
| Typical buyer | Vietnamese guest, agent, corporate client | Foreign guest booking before arrival |
| Settlement | VND into a Vietnamese account of the same legal entity | VND or USD, usually after a longer holding period |
| What slows it down | Document pack and the account name matching exactly | Merchant category review, refund policy, site inspection |
| Cost | Lower per transaction | Higher, plus currency spread and dispute fees |
We have set up OnePay and other gateways for travel merchants, and the conversation always starts in the same place: which of the two you actually need live first, and what happens to the other one in the meantime.
The part of the timeline no developer controls
This is the reason Under2 will not agree to a payment integration that has to be live in under two weeks. The code is not the constraint. The bank and the gateway review your business, and they review it at their own pace.
A reviewer opens your website and looks for things that have nothing to do with software. Is the price visible before checkout, and in which currency. Is there a cancellation and refund policy a customer could read. Does the company name on the site match the bank account and the business registration. Any one of those sends the file back and adds a week.
- We build against the gateway sandbox from day one, so the integration is finished and tested while the paperwork is still moving.
- We publish the policy pages the reviewer needs — terms, refund and cancellation, contact, company details — before the application is submitted, not after it is rejected.
- We make sure the legal entity, the bank account and the domain tell one consistent story.
- When credentials arrive, going live is a key swap and a test transaction, not a development phase.
Business registration, the bank account details of the same entity, the travel licence if the product needs one, and one named person who can sign. Projects that stall almost always stall because nobody on the client side has authority to sign the merchant application.
Deposit or full payment
A tour is not a parcel. The money can arrive in one movement or two, and that choice changes the checkout, the confirmation email and the dispute exposure.
Taking the full amount is simpler technically and harder commercially: a foreign guest booking eight months ahead may not want to hand the whole price to a company they have never heard of. A deposit is easier to sell and creates a second job — the balance has to be chased, on a date, with a working card.
| If you sell | Usually | The thing that breaks |
|---|---|---|
| Day tours and transfers | Full payment at booking | Nothing much — this is the easy case |
| Multi-day tours booked months ahead | Deposit now, balance before departure | The card expires between the two payments |
| Group and MICE | Invoice and bank transfer, no card | Reconciling a transfer that arrives without a booking reference |
| Agent and B2B volume | Credit terms, monthly settlement | A gateway adds cost and solves nothing here |
If you take a deposit, the balance reminder is part of the build, not an afterthought for the operations team. So is what happens when the balance is never paid: the booking has to expire on a defined day and release the seat, or you will find out on the morning of departure.
Refunds and cancellations
The cancellation policy has to exist as readable text before it can exist as code. We have seen more projects delayed by an undecided refund rule than by any technical problem, because the rule is a commercial decision that a developer cannot make for you.
- A refund normally goes back to the original card, not to a bank account the guest nominates, and it takes days to appear on their statement even after you send it.
- Partial refunds are common in travel and are where reconciliation goes wrong — the booking says one number, the gateway says another, the accountant has a third.
- Cancelling an authorisation that was never captured is not a refund and does not cost you a fee. Confusing the two is expensive at volume.
- Refunding in cash or by transfer when the payment came by card leaves the original charge open and available to be disputed later.
What we build is boring on purpose: every refund is recorded against the booking with who approved it and why, and the guest gets a written confirmation with the expected timing. Most refund complaints are not about the money, they are about not knowing whether it happened.
Chargebacks are different in travel
In retail, a dispute usually arrives days after a parcel does or does not turn up. In travel the service is delivered months after the money moves, and the dispute window can run from the service date rather than the payment date. A booking taken in October can be disputed the following June.
The most common trigger is not fraud. It is a cardholder who does not recognise the name on the statement, because the operating brand, the legal entity and the descriptor the bank shows are three different strings.
- Make the descriptor match the brand the guest actually booked with, and put that name in the confirmation email as well.
- Keep evidence at the time of booking, not at the time of the dispute: timestamp, IP, the exact terms text the guest accepted, the confirmation that was sent.
- Keep the operational record too — the voucher, the pickup confirmation, the guide check-in. In a dispute about a service that was delivered, that record is what wins.
- Answer within the deadline the gateway gives you. Most lost disputes in travel are lost by not replying in time.
Drop-off at the payment step, and what is actually fixable
We do not publish a percentage for how many people abandon a travel checkout, because any number we quoted would come from somebody else's store and would not predict yours. We measure your own funnel for a month instead, then separate the losses into the ones you can fix and the ones you cannot.
| What you see | Usual real cause | Fixable |
|---|---|---|
| Card declined, foreign guest | Issuer blocking a cross-border travel charge | Partly — offer a second method and say why it failed |
| Guest leaves at the price screen | Total appears only at the last step | Yes — show the full total, including options, early |
| High drop on mobile | Form fields and keyboard behaviour on a small screen | Yes — this is usually the biggest single win |
| Foreign guest confused at 3-D Secure | Bank page appears in Vietnamese only | No — but you can warn them before they get there |
| Abandoned after ten minutes | Session expired while they fetched their card | Yes — hold the booking longer and tell them how long they have |
| Price in seven-digit VND | Currency not matched to the buyer | Yes — show the currency they think in |
Two of those rows are not software problems at all. Being honest about which is which is the difference between a checkout project that pays for itself and one that redesigns a page while the real leak stays open.
When you do not need a payment gateway
A gateway costs money to run, takes weeks to approve and adds a system to maintain. There are travel businesses that should not have one, and we say so before quoting.
- Your average booking value is high and your buyers are agents on credit terms. An invoice and a transfer is cheaper and is what they expect.
- You sell mainly to repeat corporate clients who already pay by bank transfer. Adding card fees to that relationship is a cost with no new revenue behind it.
- Your product is free. Vietbuddies runs free walking tours and takes no money at all, so it has no gateway and needs none — it needs a reliable booking record.
- You take a handful of bookings a month. Fees plus approval effort plus reconciliation work will outweigh the convenience until volume changes.
- Everything you sell is sold through marketplaces that collect on your behalf. Fix the direct channel first; the gateway is the last step of that, not the first.
If bank transfer with a clear reference and a fast confirmation is working for your buyers, the money is better spent on availability and pricing being correct than on a card form.
Tell us who is buying from you
Which currencies, which countries, deposit or full payment, and what you use today. You get a written approach, a realistic approval timeline and a range.
What travel operators ask us most
How long until we can actually take a card payment?
Four to ten weeks is the realistic window, and most of it is approval rather than development. The integration itself is usually finished within the first two or three weeks and then waits for credentials.
Anyone who promises a live international card payment in under two weeks is either already approved or is not telling you where the time goes.
Can we accept payment before the company documents are ready?
Not through a gateway in your own name. Some operators bridge the gap with bank transfer and a clear invoice while the merchant application is processed, and we build the checkout so that switching on cards later is a configuration change.
We do not route payments through another entity's merchant account. It breaks the gateway agreement and it is the customer who is left exposed.
Do you handle the bank application for us?
We prepare everything the reviewer will ask for and we fix whatever on the site causes a rejection, but the application is signed by your company and the relationship is between you and the bank.
That is deliberate. A merchant account held by your supplier is a risk you would discover at the worst possible moment.
Where is card data stored?
Not on your server and not on ours. Card details are entered on the gateway's hosted page or in its hosted fields, and your system keeps only a token and the last four digits.
Under2 does not claim any payment card certification, and any build that would require one is a build we would tell you to structure differently.
Read next
Tell us what you are trying to run
What you sell, what you use today, and what is breaking. You get a written answer with an approach and a price range - not a brochure.