Understanding Bank Card Payments: Online Banking vs Quick Pay Explained

Online Banking Payment

Online banking payment was the mainstream online payment method about ten years ago. When a user places an order on an e‑commerce site, the checkout page redirects to a bank selection page, then to the bank’s own page. The bank page requires downloading a security component and using devices such as USB shields or tokens. After a successful payment, the user is redirected back to the merchant site.

The online banking flow is long; any step can fail, and some banks only support old Internet Explorer versions and require a U‑shield plugin, which reduces the overall success rate.

Quick Pay

Quick pay allows users to provide card information once; the merchant forwards the information to the payment institution, which binds the card. After binding, subsequent payments no longer require the user to re‑enter card details.

After a successful binding, the merchant can view the binding record in the bank app. Subsequent payments may still require a verification code, but limited‑amount no‑password payments are possible.

Contract/Pay

Withhold Pay

Contract/Pay

Contract/Pay consists of two steps: contract application/verification and payment. The contract step sends card number, cardholder name, ID number, phone number, and for credit cards also CVV2 and expiry date to the bank for authentication.

After successful verification, the bank sends an SMS; the user replies to confirm, establishing a binding and receiving a protocol number. The payment step uses this protocol number to deduct funds.

Withhold Pay

Withhold pay sends card information each time and can complete deduction without a password or verification code. It is simpler but carries higher fraud risk and is being gradually phased out in favor of contract‑based interfaces.

Common Issues in Card Payment Integration

Signature/Verification

Requests are signed (e.g., RSA2, national algorithms) and the payment institution verifies the signature. Responses and asynchronous notifications also need verification; failure to verify should abort the transaction.

Final State Determination

For synchronous interfaces, success is determined by response codes and sometimes by asynchronous notifications. Some codes indicate processing or system errors and require additional queries before deciding the final state.

Request Parameters

Pay attention to the amount unit (cents vs. yuan) and ensure the order amount matches the deducted amount; otherwise, do not mark the order as successful and intervene manually.

Use a unique transaction ID for each request; duplicate IDs can cause duplicate payments. An example bug used timestamps as IDs, leading to two identical IDs in the same second, causing mismatched funds.

Real‑World Pitfalls

Examples include limit‑overflow where a payment slightly above the limit succeeded but only deducted the excess amount, and various online payment logic vulnerabilities documented in public security reports.

Summary

Quick pay is currently the most popular card payment method because of its superior user experience, though it has lower security. For large‑value transactions, online banking payment is preferred. Proper testing, signature verification, idempotent processing, and careful parameter validation are essential when integrating payment channels.