Local Payment Methods: QR Transfers, E-Wallets, Cards

Payment methods follow habit, not preference

Choosing which payment methods to support is not an engineering convenience decision. The first thing to establish is how the people who will use the service already pay for things. If the checkout screen offers only an unfamiliar option, users stop at the last step, and most of those who stop never write in to ask. They simply leave.

Teams arriving from markets where cards dominate tend to picture checkout as a card form. In Vietnam the reflex for many buyers is to open a banking app, transfer, or scan a code and watch the balance change. Paying cash on delivery is still common in several sectors. Asking a first-time visitor to register a card before they have any reason to trust the service adds friction exactly where the service can least afford it.

None of this means cards are unnecessary. The answer changes with the audience. Selling to companies puts corporate bank transfers and supporting documents at the center. Serving foreign visitors means accepting cards issued abroad. A subscription that bills every month brings its own conditions. Age, the devices people use, and differences between large cities and provinces all shape which methods matter.

That is why the first question in a kickoff meeting should come before the feature list: how does the business collect money today. The offline collection process already contains half the answer. If customers are used to transferring to the company account, that habit carries into the app. If they are used to paying on delivery, moving them to prepayment is a behavior change that needs policy and careful wording, not just a new button.

This article does not assert any provider's fee rates, contract terms, or approval requirements. Those differ by bank and by payment processor, are negotiated according to sector and transaction volume, and change over time. They are for the client to confirm directly with the provider, not for a development partner to state on their behalf. What a development partner can speak to is how many steps each method adds to the flow and which additional states the server has to handle.

Yeowubie Interaction works in that order when designing screens that involve payment. List the candidate methods, sketch how many steps each one occupies in the user's path, and map where the user lands when something fails. The client chooses from that sketch. Fixing the methods first and drawing the screens later usually means rebuilding the flow.

It is better not to launch every method at once. Open with the one that is most familiar, watch what customers actually ask, then add. Each new method brings its own refund path, its own reconciliation routine, and its own support scripts. On screen it looks like one more button. Behind it sits daily operational work.

Designing for a market where transfers and QR lead

When transfers and code scanning are the primary methods, the center of gravity moves from the payment button to the confirmation step. The money moves outside your screen, inside the user's banking app. What you are building is less a payment feature and more a procedure for matching incoming funds to orders and recording the result.

The basic flow is simple. Create the order first, then show the amount, the receiving account, and an identifier for this order. The user switches to the banking app, transfers, and comes back. What matters on that screen is not visual polish but a copy button, an unambiguous amount, and a line of text telling the user where they are in the process. This screen exists so people do not lose track of what they were doing while moving between two apps.

Identification is the hard part. Even with clear instructions to put the order reference in the transfer memo, users delete it, mistype it, and each banking app allows a different number of characters. Matching based on the memo alone will not always line up. Some teams vary the last digits of the amount per order so incoming funds can be told apart, which works but requires careful wording so customers do not think the total is wrong. Whether a dedicated receiving number can be issued per order depends on the services the bank and the processor provide, and that is something to confirm before writing code.

Codes come in two shapes. A printed code stuck to the counter is easy to deploy but carries no amount or order reference, so the reconciliation burden stays where it was. A code generated per order can carry the amount and identifying information, which makes automatic matching viable. Vietnam has a shared bank code standard, so many apps can read the same code, but which fields you may include and how the code is issued depend on scope and contract. Read the official documentation before locking the design.

Whether automatic notification of incoming funds is available will drive your staffing plan. With notifications, the pending list shrinks by itself. Without them, someone opens the bank screen and checks entries one by one. A service can run either way, but you have to plan for the person who does that work every day. In that case the admin screen must include a list of unconfirmed receipts, a manual confirmation action, and a record of who confirmed what and when.

Decide the timing policy in advance. A transfer may clear in minutes or take considerably longer. If the service holds seats or stock, define how long to wait before cancelling, and define what happens when money arrives after the order was cancelled. Giving users a way to say they have transferred, or to attach a receipt, helps the support team, but that action is not proof that payment completed. The proof is covered in the next section.

To summarize, this approach looks easy to build and is heavy to operate. Going through a processor makes the screen simpler and the manual work lighter, in exchange for contractual and settlement conditions. Which side fits depends on expected transaction volume and whether someone is available to do the checking. Writing down the reasoning before development starts makes it far quicker to recalculate if the approach has to change later.

E-wallets and cards behave differently under the hood

To the user both are a single tap, but the work on the server differs. Wallets usually mean leaving for another app and coming back. Cards mean input and additional authentication happening inside your own flow. Failures appear in different places, so the screens and the exception handling have to differ too.

For wallets, the app switch is the crux. On mobile the wallet app opens, the user approves, and control returns to your app or browser. On desktop the common pattern is a code displayed for the wallet app to scan. Return paths must be registered ahead of time, and you have to test the app, the web, and the mobile browser separately. Users failing to return happens more often than teams expect: they close the app, the switch fails, the connection drops. Any design that finalizes state purely on the return trip will leak.

For cards, the working rule is to keep the card form off your own servers. Hand off to the payment page or library the processor provides so card numbers never pass through your system. That narrows the scope you are responsible for and reduces the chance of sensitive values landing in logs or error reports. When the issuing bank adds an authentication step, the flow gains another screen, along with the messaging and retry path for when that authentication does not succeed.

Domestically issued cards and cards issued abroad may be handled differently. Supported ranges, currency handling, and acceptance of foreign cards vary by processor, so those belong on a confirmation list rather than in an assertion. Currency units are another frequent source of defects. For a currency without decimal subunits, store amounts as integers and keep rounding rules in one place. Small mismatches between the screen, the server, and the reconciliation file usually start here.

Storing card credentials to bill on a recurring schedule is a separate subject. You have to design what the user consents to, where they cancel, when a failed charge is retried, and when service stops. Depending on the provider, this pattern may require its own procedure or review, so ask about feasibility and lead time early and reflect the answer in the schedule.

Put the arrival of a test environment on the timeline as well. Issuing test credentials can take time, and documentation sometimes differs from live responses in field names or descriptions. Moving to production adds its own steps for rotating keys and registering addresses. Requesting accounts while contracts are still under discussion, rather than on the first day of development, removes a common source of delay at the end of a project.

As methods accumulate, what actually grows is not the number of screens but the number of state branches. Some methods separate authorization from capture. Some allow partial cancellation and some do not. So the scattered provider states need to be consolidated into a single state model of your own. That work is what connects this section to the next one.

How you know a payment actually completed

The basis for saying a payment completed is not the success message on the user's screen. It is the notification your server received and recorded. If the screen showed success but there is no server record, that order is not complete. If the user closed the window but the notification arrived, it is. Without settling this principle early, a dispute later has no reference point.

There are generally two ways to learn the outcome: the user returning to your screen, and the processor's server sending a notification directly to yours. The first depends on the user's connection and device and can be tampered with, so it should not be the basis for finalizing anything. The second should include signature or source verification, and the amount, currency, and order reference carried in the notification should be checked against your own order. Skipping the amount check is a more common mistake than it should be.

Notifications do not arrive exactly once. The same message can arrive repeatedly, and messages can arrive out of order. So each transaction must be processed only once. Record whether a transaction identifier has already been handled, and when a duplicate arrives, respond with success quietly. Responding with an error in that situation causes the sender to keep retrying, which creates a different problem.

Build a polling path as a fallback for when notifications stop arriving. Periodically query the state of orders that have been pending too long, and surface whatever remains unresolved as a list in the admin screen. There needs to be an action for a person to make the final call, and a record of that action. Who confirmed it, when, and on what basis has to survive so the decision can be traced later. However good the automation is, leave room for a human at the last step.

Avoid copying each provider's status codes directly into your business state. Those codes differ by provider and tend to multiply. Keep only the states your operation needs, such as pending, complete, failed, cancelled, and partially refunded, and maintain a separate documented mapping to provider codes. New methods then stop disturbing the order screen and the reconciliation file. For methods with an intermediate step between authorization and capture, decide in advance how that intermediate state is treated.

It is worth stating plainly that what you keep is a record of events, not the money itself. Funds move between the payment processor, the bank, and the business. The party receiving payment and reconciling it is the business. The development partner's responsibility is to leave a verifiable trail of what happened and when. Leaving that boundary vague means that when something goes wrong, the first task becomes arguing about responsibility.

For companies with a parent entity abroad, ask the finance team early about the format they need for reconciliation. The data that circulates locally and the fields headquarters requires are rarely the same. Confirming early avoids a monthly ritual of reworking spreadsheets by hand. A requirement like that surfacing after the build is finished costs roughly twice as much to satisfy.

Plan refunds and reconciliation before you start

Building payment first and dealing with refunds later is usually the most expensive plan available. Without a refund path, every complaint is handled by hand, and that handling lives nowhere except the bank statement and a messaging thread. A few months on, the business itself cannot say what it refunded.

Refund paths differ by method. Cards work through cancellation and partial cancellation. A bank transfer means you are effectively sending money back, which requires collecting the customer's account details, and those details are personal data that has to be protected. Wallets follow their provider's rules. Whether time limits apply and whether partial refunds are possible also depend on the provider and the agreement, so they belong on the confirmation list. Building a refund button before confirming any of this produces a button that does not work.

So the policy comes first. How long refunds remain available, whether partial refunds are allowed, whether a cancellation charge applies, who approves, and how many days you tell the customer it takes. These are commercial decisions rather than technical ones. Without them the screens cannot be built, and if the development partner decides unilaterally, the work gets reversed later. Put these items near the front of the requirements document.

On the reconciliation side, what a development partner produces is ledger-shaped data used for matching. The identifier linking order to transaction, the method used, the state and timestamp, and the provider's transaction reference should sit on one row so finance can line things up. When the money actually lands, how fees are deducted, and how tax is handled sit between the business, the payment processor, and the bank. Judgments about licensing for payment activity and about handling funds belong to the competent authority and to professional advisors, and a development partner does not make them on anyone's behalf.

The questions that need answers before development starts are fairly consistent. Who is the contracting party, which methods will open, how completion notifications arrive and which fields they carry, when test credentials become available, what the path to production looks like, how far the system can go in processing refunds, and what format finance needs. Starting on screens while those blanks remain is how rework cost shows up at the end.

Start small. Open with the single most familiar method and let the responsible person run real reconciliation for a month. The questions raised during that month will tell you what to add next. Where customers hesitate, which misunderstandings repeat, how many minutes a day the checking takes: all of it becomes visible then. Adding methods without that observation makes the interface busier and the operation heavier.

Payment is closer to a procedure than to a feature. Screens can be assembled in a few days, but procedures are run by people. Projects that settle early on what needs confirming and who decides tend to finish sooner. Simply avoiding a schedule where payment gets bolted on in the final days removes most of the incidents.