# Building a QR Payment Checkout? Plan for Failed Connections

Displaying a QR code is easy. Building a checkout that handles delayed notifications, duplicate events, and uncertain payment outcomes takes care.

For developers exploring Asian payment technology, the starting point is the transaction lifecycle.

Create the Order Before the Payment

Store an order identifier, amount, and currency before requesting payment.

Associate each payment attempt with its provider reference. Keep separate attempts distinguishable so support staff can investigate what happened.

Never assume that scanning a code means the customer has paid.

Define Clear Payment States

Start with states such as created, pending, confirmed, failed, and expired. Map them to your provider's documented behavior.

Treat refunds separately because a confirmed transaction may later be partially refunded.

For each transition, specify:

• Which provider event can trigger it.
• Which transaction reference must match.
• Whether the amount and currency match.
• How repeated events are handled.

A browser redirect should not independently mark an order paid.

Make Duplicate Events Harmless

Design event processing so repeated notifications cannot trigger repeated fulfillment.

Authenticate callbacks using the provider's documented method. Store event identifiers where available and update transaction records atomically.

If your application times out, check the original transaction before starting another attempt. Missing confirmation does not necessarily mean failure.

Reconcile What Actually Happened

Connect order records with payment attempts, refunds, and settlement reports.

Give staff a reliable merchant view instead of relying on customer screenshots.

Test delayed callbacks, mismatched amounts, expired codes, and interrupted connections in the provider's sandbox.

I publish explanations of Asian banking and payment technology at FTAsiaStockTechnologies, which I run.

A reliable checkout needs more than a successful demo. It needs predictable behavior when systems disagree.

Which failure case would you test before letting your customer pay?