Payment Gateway in Taiwan: A Route-by-Route Merchant Guide

A payment gateway in Taiwan should connect each enabled payment method with clear checkout, confirmation, currency, refund, and settlement rules.

For a gaming, subscription, content, or digital-goods business, a provider logo is only the start. The practical questions are what the shopper must do, what the merchant system receives, and when fulfillment is safe. Merchants should also separate the order currency from the currency eventually paid to their bank account.

HaiPay’s public documentation lists Taiwan collection routes for JKOPay, LINE Pay, automated teller machine (ATM) payments, and several convenience-store journeys. These listings support initial evaluation. Actual method availability and limits must be checked against the merchant’s application configuration. Pricing, settlement, and other commercial terms should also be confirmed in the written agreement [1–3,8].

Source: Public route documentation, merchant-configuration fields, and written-commercial-term guidance, accessed September 7, 2026 [1–3,8].

Choose payment methods by shopper action

The useful comparison is the action a shopper completes on each device. An application programming interface (API) category may not be the right label for checkout.

Taiwan payment-route evidence matrix

The following matrix reflects public documentation checked on September 7, 2026. “Not verified” means merchant-specific evidence was unavailable; it is not a negative capability claim.

The public API places its LINE Pay route under a technical bank-transfer value. LINE Pay’s own material describes a website and app payment service. Use a shopper-facing LINE Pay label while retaining the documented technical value only in integration settings [1–2,9].

Source: Public route tables, merchant-configuration, integration and pricing documentation, the merchant FAQ, and official payment-operator and store instructions, accessed September 7, 2026 [1–4,7–14].

Verify the active merchant configuration

A public country table does not establish which methods are active for a specific merchant. The merchant-configuration documentation describes an application-level request. Its response can include the collection currency, method, merchant-specific limits, fee structure, settlement mode, and refund-support field. An unconfigured payment product returns an empty configuration list [3].

Use the response to create an approval matrix before development begins:

This account-level check is necessary because the two public route tables disagree on the TWD ATM minimum. They also disagree on whether the TWD OK Mart route is available or under maintenance. The Taiwan API’s overall TWD minimum differs from the lower method-level values shown for JKOPay. Treat these values as configuration questions rather than universal limits [1–2].

Source: Application-specific configuration documentation and two public route tables with conflicting public values, accessed September 7, 2026 [1–3].

Separate the four currency layers

TWD and USD in an endpoint or route table identify an order or route currency. Those fields alone do not establish what a shopper sees, how any conversion occurs, or what reaches the merchant’s bank.

Document four separate fields for every method:

1. Order currency: the currency and decimal rules sent in the payment request.
2. Shopper currency: the amount and currency displayed and funded at checkout.
3. Platform settlement currency: the currency used for the merchant balance or settlement calculation.
4. Bank payout currency: the currency transferred to the nominated bank account after any conversion and bank processing.

The Taiwan API documentation describes separate TWD and USD collection endpoints. It returns a payment link and defines TWD as integer-only, while USD accepts two decimal places. Its LINE Pay entry appears only on a USD route; this does not establish a TWD-native LINE Pay option [1].

These facts support request validation. They do not prove the shopper display currency or final bank payout currency. Obtain a test order, checkout capture, callback record, settlement report, and bank receipt for each currency model. Reconcile the order amount, any converted amount, fee, net settlement, payout, and bank credit.

Source: Taiwan API documentation for TWD/USD endpoints, decimal rules, payment link, and the LINE Pay route, accessed September 7, 2026 [1].

Treat browser return and payment confirmation as separate events

A browser return helps the shopper continue, but it should not be the only fulfillment signal. The Taiwan collection request includes success and failure return addresses, an optional server notification address, and a payment link in its response. The query interface distinguishes not started, processing, final success, final failure, final partial receipt, final over-receipt, and an exception awaiting confirmation [1].

Use this implementation checklist and validate it against the enabled methods:

1. Create a unique order and store the merchant and platform order references.
2. Send the shopper to the returned payment link.
3. Show a pending page when payment is not final, especially for ATM and store methods.
4. Validate the signature on a server notification and ensure repeated delivery cannot trigger duplicate fulfillment.
5. Query the order when a notification is missing, delayed, or ambiguous.
6. Fulfill only after the approved final state and amount checks pass.
7. Route partial, excess, failed, and exception states to documented operations rules.

The integration guide describes the core sequence as order creation, payment details, asynchronous notification, and parameter and signature validation. The onboarding checklist also calls for duplicate-callback handling, idempotency, invalid-parameter tests, and coverage of every error and status [4,6].

Source: Taiwan collection/query fields, the integration guide, and the onboarding checklist, accessed September 7, 2026 [1,4,6].

Plan ATM and convenience-store payments as asynchronous operations

The merchant FAQ describes ATM and convenience-store payments as offline services with a payment window. Treat an order as pending until the configured authoritative status confirms payment [7]. Expiry, reminders, stock reservation, entitlement release, and unpaid-order cleanup therefore belong in the payment design.

Official operator pages explain the physical action without proving a provider-specific flow. The 7-Eleven ibon page shows a shopper entering or scanning a payment code, retrieving the record, displaying a barcode, and paying at the counter. FamilyMart describes an online-purchase payment code entered at FamiPort. OK Mart describes a code-payment channel for online shopping [12–14].

Test these cases for every enabled method:

• payment before expiry;
• abandonment without payment;
• payment near or after expiry;
• duplicate browser returns and notifications;
• a paid order whose browser never returns;
• partial or excess receipt where the method can produce it;
• refund, cancellation, or manual resolution;
• matching the payment to settlement and payout records.

Article 45 of Taiwan’s Rules Governing the Administration of Electronic Payment Business applies when a specialized electronic payment institution outsources the collection of user payments made in cash in TWD. In that defined situation, it requires a security-control plan and a reconciliation mechanism. Collection information must be transmitted, confirmed, and checked immediately when the outsourced provider receives payment.

Except where Ministry of Finance rules set another cap for tax payments collected at convenience stores, the outsourced provider’s per-transaction collection cap is NT$20,000 or its equivalent. The rule does not establish the provider’s legal status, merchant eligibility, or any method-specific limit [15].

Source: Merchant FAQ, official 7-Eleven, FamilyMart, and OK Mart instructions, and Taiwan Banking Bureau Article 45, accessed September 7, 2026 [7,12–15].

Compare pricing, settlement, and payout separately

Fees can vary by method, currency, transaction profile, settlement setup, and service requirements. The pricing page says a written proposal should identify approved methods and currencies, pricing, transaction fees, settlement currency and schedule, and contract conditions. It also lists foreign-exchange, refund, dispute, network, integration, and support charges as items that may be separate [8].

Compare the effective cost of the intended method mix. For each route, record:

• percentage and fixed transaction fees;
• foreign-exchange and cross-border costs;
• refund, dispute, and chargeback handling;
• failed-payment and manual-review effort;
• settlement calculation and release timing;
• payout schedule and expected bank transit.

Use the signed agreement as the commercial source of truth. Record the settlement tier, payout schedule, and bank transit as different events. Confirm whether cycle values count calendar or working days and how holidays affect execution. The merchant-configuration response can expose fee and settlement fields, but a real account result was not available for this review [3].

Source: Pricing and merchant-configuration documentation for quote scope, potential separate charges, fee fields, and settlement fields, accessed September 7, 2026 [3,8].

Decide whether the setup fits

This approach can fit a merchant that needs local wallets, ATM, or convenience-store payments alongside an international checkout. The team must be prepared to test asynchronous states, reconcile several payment journeys, and obtain route-specific commercial terms.

It may not fit a business that needs every publicly listed method activated immediately, assumes every local method supports recurring payments, or requires one universal limit and settlement schedule. A cards-only recurring business needs a separate card, authentication, subscription, and dispute assessment.

Use a written pass-or-fail rule for each required method: configured for the merchant, tested on the intended device, reconciled through payout, and covered by the signed agreement. A missing result keeps that method outside the launch scope.

Source: Decision framework derived from documented application-specific configuration, testing, onboarding, and pricing fields, accessed September 7, 2026 [3,5–6,8].

Use this Taiwan launch checklist

• Query and archive the production merchant configuration for every application.
• Match each payment code to a shopper-facing label and device journey.
• Test desktop, mobile browser, in-app browser, app handoff, scannable-code, and store-terminal paths where applicable.
• Validate signatures and ensure duplicate notifications cannot release goods twice.
• Define fulfillment rules for every final and non-final status.
• Confirm expiry, late-payment, partial-payment, excess-payment, cancellation, and refund handling.
• For subscriptions, confirm first payment, renewals, reauthorization, retries, and cancellation for each method.
• Reconcile order, fee, settlement, payout, and bank receipt records.
• Keep order, shopper, platform settlement, and bank payout currencies in separate fields.
• Obtain written pricing, settlement, payout, and support terms for the approved method set.
• Recheck route status and limits immediately before launch.

The test and production environments use separate accounts and application identifiers. The test environment can simulate order-status changes and send notifications. The production checklist then calls for real-information testing and complete status, callback, and error handling [5–6].

For the broader architecture, compare this route checklist with the local payment coverage and international payment gateway guide.

If Taiwan is part of your checkout plan, request a route-level assessment and written quote for your entity, methods, currencies, device mix, recurring needs, refunds, settlement, and bank payout requirements.

Source: End-to-end testing guide and onboarding checklist for test-environment functions and production-readiness checks, accessed September 7, 2026 [5–6].

Evidence and scope

HaiPay publishes this guide and provides payment services. The guide is educational and does not provide legal, tax, financial, or investment advice. Public route and operator documentation was checked on September 7, 2026. Merchant availability and commercial terms depend on account configuration, testing, and the signed agreement.

The public documents disagree on some route limits and status values. This guide identifies those conflicts instead of selecting one value. No merchant configuration response, production checkout, settlement report, payout record, or signed quote was supplied for this review.

Source: Scope and freshness disclosure for sources [1–15].

Sources

1. HaiPay — Taiwan API — route identifiers, TWD/USD endpoints, decimal rules, application fields, query states, and conflicting public limits; accessed September 7, 2026.
2. HaiPay — Collection Payment Methods List — public route classifications, limits, and status values used for conflict comparison; accessed September 7, 2026.
3. HaiPay — Get Merchant Payment Config — documented application-specific methods, limits, fee, settlement, and refund-support fields; accessed September 7, 2026.
4. HaiPay — Integration Steps Guide — order, notification, parameter, and signature workflow; accessed September 7, 2026.
5. HaiPay — End-to-End Testing Guide — test-environment status and notification functions; accessed September 7, 2026.
6. HaiPay — Onboarding Checklist — separate environments, production testing, callback, idempotency, status, and error checks; accessed September 7, 2026.
7. HaiPay — Frequently Asked Questions and Troubleshooting — description of Taiwan ATM and convenience-store payments as offline services with a payment window; accessed September 7, 2026.
8. HaiPay — Payment Gateway Pricing and Fees — written-quote scope and potentially separate commercial components; accessed September 7, 2026.
9. LINE Pay — Taiwan Payment Service — official website and app payment steps; accessed September 7, 2026.
10. JKOS — Open Documentation — official online-payment API categories and merchant integration surfaces; accessed September 7, 2026.
11. JKOPay — Customer Payment Guide — official desktop QR, mobile app handoff, and funding-source instructions; accessed September 7, 2026.
12. 7-Eleven ibon — Code Payment — official code, QR, barcode, and counter-payment steps; accessed September 7, 2026.
13. FamilyMart FamiPort — Code Payment — official online-purchase code-payment description; accessed September 7, 2026.
14. OK Mart OK-go — Code Payment — official online-shopping code-payment channel description; accessed September 7, 2026.
15. Taiwan Banking Bureau — Article 45 — official English text for outsourced cash-collection controls, reconciliation requirement, ceiling, and exception within the rule’s scope; accessed September 7, 2026.