Payment Gateway Integration in Taiwan: Choosing Methods, Running the Integration, and Handling Reconciliation and Refunds
On the feature list for an e-commerce site, payment integration often occupies a single line. In practice it is the segment most likely to delay the whole project.
The reason is not that the code is difficult. It is that payments simultaneously involve applications and approvals, financial process, exception handling, and security responsibility — four things owned by four different roles. This guide sets out the path from selection to launch so you know who does what at each stage, and what to ask.
The payment methods commonly used in Taiwan
Start with the consumer’s options, because they directly determine how many services you need to apply for and how many reconciliation flows you have to handle.
Credit cards: the most widespread, and the only major method that supports installments and recurring charges. Note that cardholder verification — the step where a one-time code is entered — affects both completion rates and where liability sits in a dispute. Treat the current rules of the card schemes and acquiring institutions as the authority.
Convenience store code payment: the system generates a code and the customer pays at a convenience store. Convenience stores are everywhere in Taiwan and function as a standard payment and parcel pickup network. The defining characteristic is order first, pay later — the money has not arrived when the order is created, so your system needs an awaiting-payment state and automatic cancellation once the deadline passes.
ATM virtual accounts: a dedicated account number is generated for each order, and the system matches the transfer automatically. This is also order-first, pay-later, but far more reliable than manually matching the last digits of a remittance.
Mobile payments and e-payment services: the customer completes payment on their phone. The experience is smooth and completion rates on mobile devices are usually better. Application conditions and permitted use cases differ by service and need to be confirmed individually.
Cash on delivery: payment is collected by the logistics provider. The barrier is low, but uncollected parcels and the settlement cycle for collected funds both have to be built into your cash flow planning.
The time it takes for money to reach you varies considerably between methods, and that directly affects your working capital. When choosing, do not look only at what is convenient for the customer — also ask when the funds land in your account.
Payment service provider versus a direct bank arrangement
This is the first decision point. Neither model is superior; the difference is how much you are willing to handle yourself.
| Dimension | Payment service provider | Direct bank arrangement (merchant account) |
|---|---|---|
| Obtaining payment methods | Several at once | Usually applied for individually |
| Development workload | Smaller, one interface | Larger, integrated separately |
| Application process | Single point of contact | Negotiated one by one |
| Reconciliation | Consolidated reporting provided | You integrate multiple sources |
| Room to negotiate terms | More fixed | More flexible |
| Who it suits | Growing volume, wanting to launch fast | Stable volume, with finance and engineering resources |
The common path in practice is to launch quickly with a provider, then reassess once transaction volume and requirements have settled. That matches the principle behind most system selection: validate that the business works before optimizing the cost structure.
Whichever route you take, ask every candidate the same set of questions: which payment methods are supported, the settlement and payout rhythm, how refunds are performed, the process and liability allocation when a dispute arises, whether technical documentation and a test environment are complete, who to contact when integration goes wrong, and whether any amount or product category restrictions apply. Rates vary by business type and transaction volume, so obtain a formal quotation directly from each provider rather than relying on older information found online.
What application and integration actually involve
The timeline of a payments project generally looks like this:
Stage one: application. Prepare company registration documents, details of the responsible officer, a description of your business activities, and the content of the website or app. The reviewer will look at what you sell, whether product descriptions are clear, and whether returns and customer service information are complete. This stage frequently stalls because the site is not live yet, so start the application as the project begins and run it in parallel with development. Some product categories carry special requirements or are not accepted at all; if your products fall into an unusual category, confirm that first.
Stage two: technical integration. The development team follows the provider’s documentation to do three things: send the order information out, receive the payment result notification, and update the order status in your own system. It sounds simple, but the last two are where the difficulty lies — a payment result notification may be delayed, may arrive more than once, and may arrive only after the user has closed the window. The system has to handle all of those correctly.
Stage three: testing. Work through every scenario in the provider’s test environment.
Stage four: launch and observation. For the first few days, manually reconcile transactions and incoming funds to confirm the automatic reconciliation logic is correct.
For why integration projects tend to overrun and what to inventory in advance, see the Guide to System Integration and API Development.
The scenarios your test environment has to cover
This is the segment most often done inadequately. Beyond a successful payment, every one of the following needs to be verified in practice:
- Whether the order status is correct after a failed payment, whether from insufficient funds or a declined card
- What happens to the order when the user closes the window mid-payment
- Whether the system still updates correctly when the result notification arrives late
- Whether a duplicated notification causes double crediting or double shipment
- Whether order-first, pay-later methods cancel automatically and release inventory when payment is not made in time
- Whether amounts and product information can be tampered with from the front end
- Whether order and inventory status remain consistent after a refund or a partial refund
Two of these deserve the most attention: duplicate notifications and amount tampering. The first is handled by de-duplicating on a unique identifier, so that processing the same notification repeatedly produces the same result. The second is handled by recalculating the amount on the server and never trusting a figure sent back from the browser. For how to write acceptance conditions and who signs them off, see the Software Acceptance Testing (UAT) Guide.
Reconciliation and refunds: the work that starts after launch
Reconciliation means bringing three records together: the orders in your system, the transaction log from the payment provider, and the money actually arriving in your bank account. When they fail to match, the cause is usually a missed notification, a failed status update, or a timing difference created by fees and payout schedules.
The practical approach is to compare automatically every day and surface the differences automatically, rather than discovering the problem at month end. Design the system to retain a complete record and timestamp for every transaction, so investigations later have something to work from.
Refunds require several decisions up front: who has permission to issue them, whether a second confirmation is required, how partial refunds are calculated, what happens to the order and to inventory afterwards, and how the refund record is retained. One point in particular: partial refunds must be prevented from exceeding the original transaction amount in aggregate. That is a genuine class of defect seen in practice, and the cap check belongs in the design from the start.
Disputes are the other thing to understand in advance. When a cardholder raises a dispute with their issuer, you may need to supply proof of shipment, service records, or conversation screenshots. Keep shipping and support records complete, because when a dispute arrives they are the only evidence you have. Processes and deadlines differ by institution and change over time, so treat current official guidance as the authority.
Baseline security and compliance principles
The card industry has its own data security standard, commonly referred to as PCI DSS. In plain terms: the moment your system touches a full card number, you take on an extensive set of strict protection obligations.
That is why the mainstream approach is for cardholders to enter their card number directly on a page or component supplied by the payment provider, so your system receives only a token representing that card along with the transaction result. The full card number never passes through, and is never stored on, your servers, which sharply narrows the responsibility you carry.
Beyond that, the fundamentals still apply: encrypted connections site-wide, individually assigned admin accounts with tiered permissions, traceable logs for critical operations, production and test keys stored separately and never written into the code, and regular updates to systems and libraries. These are covered more fully in Website Security Basics for Businesses.
If you are building a marketplace where the platform collects from buyers and pays out to sellers, there are regulatory thresholds for collecting payments on others’ behalf to confirm on top of the integration itself; see “Escrow and completion guarantees” in Marketplace Platform Development.
Requirements and provider rules keep changing, so always implement against current official documentation, and have a lawyer review anything touching contracts and liability.
Three common misconceptions
Misconception one: treating payments as work for the final week of development. Application and approval are outside your control of the schedule, so they should start first.
Misconception two: testing only the success path. What actually produces complaints and accounting chaos is the failure and exception paths.
Misconception three: comparing on transaction fees alone. Payout rhythm, ease of refunds, dispute handling support, and documentation quality frequently matter more to operations. For how to look at total cost, read alongside How Website Costs Are Calculated.
Customers only notice how well payments were built when something goes wrong — and that single occasion usually decides whether they come back. Finishing the exception testing and automating reconciliation are both more worthwhile than adding one more payment method.
If you are planning an e-commerce site, or your current payment flow keeps producing figures that will not reconcile, discuss your requirements with NETVANA. NETVANA consults before quoting and does not sell fixed packages; once final payment is received, source code and documentation are transferred in full. What each service includes and delivers is set out in the software services overview.
Further reading: to decide which route your e-commerce build should take, see Building an E-commerce Site; to manage site content yourself, see How to Choose a CMS; and to connect other systems, see the Guide to System Integration and API Development. For where orders and stored value land in your member records, see Building a Membership and CRM System. For the invoice that has to follow every successful charge, see Integrating the Taiwan E-Invoice System; and for the shipping side that cash-on-delivery ties into, see Logistics Integration in Taiwan; and for in-store payments and how they reconcile differently, see POS and Retail System Development. Escrow and payouts on a marketplace run on the same payment integration basics, with added regulatory questions; see Marketplace Platform Development.
