Apps That Move Money: Decide This Before You Build
What Changes Once Money Moves Inside Your App
The moment payments are added, an app stops being only software and becomes a segment of a money flow. Whose account receives the funds, who is answerable for refunds, what records must be kept and for how long: all of it appears at once. In Vietnam, currency, local payment habits, and business licensing conditions are layered on top. Structure decisions come before technology choices.
Seen as a feature list, payments look like one more screen. A payment method picker after the cart, a success screen, done. What actually grows is not the screen count but the responsibility. When a charge fails but the money leaves the account, when the same request arrives twice and is billed twice, when a user cancels after the seller has already shipped, the service has to judge and repair the situation on its own. Those judgment rules belong to the business side and need to exist before anyone writes the integration.
The sharpest local variable in Vietnam is the breadth of payment methods. Bank transfer, QR code payment, e-wallets, cards, and cash on delivery all coexist inside one service. Each has a different moment of confirmation and cancellation, and each reports failure differently. Some settle in seconds, others need a human to check before they are final. Hiding that spread behind a single screen means the state handling underneath has to be far tighter: the classic stretch where the interface looks simple and the server does not.
The cost of reversal is also different. An ordinary feature built wrong gets fixed in the next release. A record of money that moved cannot be overwritten. Pulling back a payout that has already gone out requires a negotiation between people, and trust is the first thing spent there. That is why a project with payments needs a denser set of questions at kickoff.
The questions that must be answered before starting usually collapse into four. Which entity actually receives the money. How many hands does it pass through before reaching the final recipient. Whose name answers to the user when something goes wrong. If this flow has to be evidenced later, what records need to survive. Once those four have answers, the payment integration itself becomes ordinary work. Start building without them and the integration finishes while the service still cannot open.
One thing worth adding. An app with payments also carries a heavier operating load. Reconciliation, inbound questions, refunds, and month-end close repeat daily or weekly. This rarely shows up in a development quote, yet it consumes real staff time. For a small team, it is better to open only as much payment scope as operations can carry and widen it gradually. Running our own products has confirmed this repeatedly: what decides an organization's stamina is the work that recurs after launch, not the build itself.
Why the Collecting Party and the Settling Party Come First
The collecting party is the legal entity the user's money first flows into. The settling party is whoever splits that money and sends it on to the final recipients. They may be the same or different. This single choice determines contract wording, receipts and evidence, refund liability, accounting treatment, and the business qualifications you need to hold.
The most common misreading is treating it as a technical setting. Integration documents have a field for the merchant account, so it feels like the only question is what to put in the field. In practice, the name in that field is the party contracting with the user. When a refund is demanded, when a tax authority asks for the basis of a transaction, when a dispute escalates into a consumer protection process, that is the name standing in front. If the brand on the screen and the actual collecting party differ, the gap comes back as a problem eventually.
For services with several participants, the path forks. In one branch the platform gathers the funds once and then settles them outward. In the other, money goes directly to the seller or provider and the platform collects only its fee separately. The first branch gives a smoother experience and puts dispute handling in one place. In exchange, it takes on the character of holding and forwarding other people's money. How far that is permitted, and whether it requires separate registration or licensing, depends on the business form and the rules in force, so it has to be confirmed with local counsel. The second branch reduces that burden but scatters accounts and payout cycles across sellers, and moves refunds and disputes out of the platform's hands.
A cross-border element adds another layer. A team in Korea building a service that runs in Vietnam is a common arrangement. In that arrangement there is no reason the software builder and the money recipient must be the same entity. Keeping them separate is often the normal structure. Reviewing structures across several services, we have run into the same judgment more than once: when settlement transparency is the core value of the service, the party that receives and distributes the funds needs real presence in the local market. That is not something clever engineering routes around. Attempts to route around it produce a system that works technically and a service that cannot open commercially.
So it is better not to invert the order. Set the corporate and contractual structure first, choose the payment methods and settlement flow that fit it, and write the code last. Going the other way means discarding work. Payment integration soaks into the data model, the state machine, and the permission system, so a change in the collecting party rewrites the spine of the server rather than a few screens.
One artifact is worth producing during this decision. For every leg the money travels: the sending and receiving names, the contract that justifies that leg, the fees and tax treatment arising there, and the method of reversal when something breaks. With that single table, the development team, accounting, and outside advisors can talk about the same picture. Without it, each party holds a different picture and mistakes it for agreement.
The Fork Between Store In-App Purchase and External Payment
For a mobile app, the question of whether store in-app purchase is required or an external payment method is allowed arrives early. Broadly, digital goods and subscriptions consumed inside the app tend to fall under store billing, while physical goods and services delivered outside the app leave room for external payment. The criteria and the exceptions keep changing.
This fork matters for more than fee rates. With in-app purchase, the store is the party receiving the money, and payout cycles, currency conversion, and refund decisions follow the store's rules. The business sits in the position of receiving settlements from the store. With external payment, funds arrive on the business side directly, and the business designs and owns settlement, evidence, and refunds. The same revenue takes a different shape in the books and moves at a different speed.
Specific fee percentages, small-business exceptions, and how far you may signpost or link to outside payment all live in each store's policy documents and shift by period and region. That is why this article does not state those numbers or conditions as settled. Read the current policy documents directly before submitting for review, and for anything sitting on a boundary, ask the review team in advance. A pattern that passed last year is not guaranteed to pass this year.
One place in the Vietnamese market gets genuinely confusing: payment happens inside the app while the actual delivery is by a physical venue or a person. Bookings, lesson matching, and on-site services live here. On the surface it is in-app payment, but the delivering entity sits outside the app, so classification can differ. Among our own products there is a service that connects learners with teachers. In a structure like that, it is safer to make explicit at design time that the app is where the connection is made, and that the delivery and the exchange of value sit between the participants themselves. If that boundary is blurry, questions arrive from store review and from local requirements at once.
The design recommendation is plain. Do not nail the system to one payment method. If the domain layer that handles orders, products, prices, and refunds is kept separate from the payment method layer, running both models side by side later, or moving entirely to one, touches far less code. Procedures that exist only in the store world, such as receipt validation, subscription state synchronization, and refund notifications, are better sealed inside an adapter.
If you choose to run both, plan for reconciliation splitting into two streams. Store settlement statements and your own transaction history differ in currency notation, the moment of recognition, and how refunds are reflected. Most month-end mismatches originate right there. Normalizing both sources into a single ledger format from the beginning cuts a great deal of the manual matching people would otherwise do later.
Structuring a Service That Needs Settlement Transparency
When one payment is divided among two or more recipients, settlement is not a side feature but the body of the product. Marketplaces, store operation platforms, matching services, dispatch, and delivery all belong here. The first thing a participant checks is not how polished the interface is, but whether their share arrived correctly.
Start with how records are kept. A transaction ledger is safest as an append-only structure. Storing state in one column and updating it continuously tells you the current value while erasing the path that led there. Write authorization, cancellation, partial refund, fee deduction, and hold release each as its own line, then compute the current balance as the sum of those lines, and the service becomes one that can explain itself during a dispute. Being able to explain is what trust is made of.
Duplication and ordering need handling up front too. A payment request can arrive twice because of the network, and notifications from the payment provider can arrive out of order or repeat. The design needs an identity key such that processing the same transaction any number of times yields the same result as processing it once. Build notification handling on the assumption of retries, and add a step that queries the provider's state again rather than trusting the notification alone. Without those three things, reconciliation turns into daily manual patching.
Currency handling needs rules agreed in advance. The Vietnamese dong is, in practice, not used with decimal fractions. Multiplying by a fee rate always leaves a remainder, and unless you decide who takes that remainder and which way it rounds, differences that are trivial per transaction accumulate into a monthly figure that does not balance. Write the rounding rule into the documentation and implement it in exactly one place in the code.
Payout cycles and hold rules are business decisions. When amounts become final, when they are paid, and how long anything disputable is held all directly affect participants' cash position. More important than setting the rules is making them visible to participants in advance. If a statement screen lets someone see what this cycle includes, what is being held, and why, the volume of questions drops sharply. Show only a total and every question lands on a person instead.
The judgment from the earlier section returns here. The more a service depends on settlement transparency, the more the question of who actually holds and distributes the funds has to precede the technical design. However carefully the ledger is built, if the receiving and disbursing entities do not fit local requirements, the ledger only records a service that cannot open. For this class of service, the technical design and the entity design belong in the same meeting.
Finally, audit traces. Who changed which settlement rule and when, from what date a fee rate applied, under whose approval a manual adjustment was processed: all of it must survive. Manual intervention in settlement will happen. The intervention itself is not the problem; the absence of a record of it is.
What Needs Confirming and What to Ask Specialists
Everything above concerns structure. What follows is the set of items this article cannot answer, because they vary by business form and by moment, and must be confirmed directly with local specialists. Rules in Vietnam are amended and applied case by case. Starting development on unconfirmed assumptions makes reversal expensive.
Begin with business qualification. Whether the registered scope of business covers the activity you intend to run. Whether the activity counts as e-commerce or online intermediation and therefore needs its own registration or notification. Whether an entity with foreign investment faces additional conditions for that activity. And how the act of temporarily holding funds and passing them to a third party is categorized. That last item comes up almost every time with marketplace-shaped services, so ask before locking the structure.
Next, tax and evidence. What documentation must be issued at each step of a transaction, how platform fees and sale proceeds are separated, whether withholding obligations arise when paying individual participants, and what procedures attach to funds and service fees crossing a border. Rates and filing cycles are outside this article. The accurate route is to draw the business structure as a diagram, hand it to an accounting advisor, and get answers leg by leg.
Data and consumer protection belong on the list as well. Where payment-related personal data must be stored, what retention periods and access controls are expected, and how far a configuration that never touches card data directly reduces those obligations. Alongside that, how refund and cancellation policies must be disclosed. Store review sometimes asks the same questions, so preparing once for both saves a round.
For payment methods, asking the provider's onboarding team directly is fastest. What documents are required, which business categories are supported and which are excluded, what the payout cycle and hold policy look like, and what the business is expected to do when a dispute is filed. This article names no specific provider, because eligibility varies with business form. Sending the same question set to two or three and comparing the answers side by side is the more useful approach.
Store policy is an item to recheck immediately before submission. Whether your product type falls under in-app purchase, how far you may signpost external payment, and how the app must handle subscription cancellation and refunds. Documents change, and the changed document is the review standard. Carrying what you read at kickoff into a submission months later is not safe.
There are three places to ask. Entity form, permitted scope, and the nature of handling funds go to local legal counsel. Evidence and tax treatment go to a local accounting advisor. Settlement terms and onboarding eligibility go to the payment provider. The development team turns those three sets of answers into system structure. That is largely what we do early in a project: not answering on anyone's behalf, but building the list of questions and adjusting the design as answers come back.
The order, plainly: decide the collecting and settling parties, confirm with advisors what those parties require, choose payment methods and check store policy within the confirmed scope, and only then build the ledger and reconciliation. Keep that order and development becomes predictable. Skip it and well-built software sits there unable to open.