A production checkout has harder questions. What happens if the customer pays but the notification arrives late? What if a callback is delivered twice? Can staff distinguish a payment confirmation from a screenshot?

For developers building payment experiences, those cases should shape the architecture from the beginning.

Separate the Code From the Payment

EMVCo's QR specifications distinguish merchant-presented and consumer-presented modes. In the first, customers scan a merchant's code; in the second, merchants scan the customer's code.

The specifications address the encoded data format. Payment providers define the subsequent messaging and processing.

That boundary matters: decoding a valid payload does not establish that money moved. Your integration must use the selected provider's transaction interfaces and confirmation rules.

Give Each Order a Stable Identity

Before initiating payment, create an order record with an internal identifier, amount and currency. Associate the provider's transaction reference with that record.

Where supported, request a transaction-specific QR code rather than relying on customers to type an amount manually.

Keep customer-facing order references separate from sensitive internal details. Never place credentials or unnecessary personal information inside a QR payload.

Model More Than Success and Failure

A useful starting model includes created, pending, confirmed, failed and expired states. Treat this as an application design proposal and map it to the provider's documented lifecycle.

Track refunds separately, since a confirmed payment can later be partially or fully refunded.

For every transition, decide:

• Which authenticated provider event can trigger it?
• What amount, currency and transaction reference must match?
• Can the event arrive more than once?
• What happens if events arrive out of order? Do not mark an order paid merely because the customer's browser returns to a success URL.

Make Confirmation Safe to Repeat

Providers can have different callback delivery guarantees. Design your own handling so repeated events do not trigger repeated fulfillment.

Validate callbacks using the provider's documented authentication mechanism. Record event identifiers when available, and apply transaction updates atomically.

After a timeout, query the original payment status before creating another attempt. A timeout means your application lacks a final answer; it does not necessarily mean the payment failed.

Build a Reconciliation Path

Customer confirmation, merchant notification and settlement are separate events in many payment systems. Confirm the exact behavior with your provider.

Maintain records that connect orders, payment attempts, refunds and settlement reports. Give support staff a way to investigate mismatches without asking customers to expose sensitive account details.

For broader context on Asian banking and payment technology, I publish explainers at FTAsiaStockTechnologies, which I run.

Test the Awkward Cases

Before launch, simulate duplicate callbacks, delayed confirmations, amount mismatches, expired codes and refund requests in the provider's sandbox.

Also check displayed codes for substitution and teach staff to verify payment in the merchant system.

A reliable QR checkout is an order-management workflow connected to a payment service. The scan starts that workflow; clear state transitions, authenticated confirmation and reconciliation make it usable when something goes wrong.

For developers, this is a data design problem before it is a prompting problem. A useful prototype should preserve evidence from ingestion to the final answer.

Here is a practical architecture for a research assistant that makes its output easier to check.

1. Start With Structured Financial Data

The SEC's EDGAR APIs provide company submission histories and extracted XBRL financial data in JSON. They do not require API keys.

Use the company's Central Index Key, or CIK, as an identifier. Keep the source response alongside the normalized records so later transformations can be audited.

Do not assume every company uses the same tags or reporting calendar. A missing standard concept should remain missing until you establish a reliable mapping.

2. Store Context Alongside Every Number

A financial value without its reporting context is an incomplete record.

For each observation, preserve:

• Company identifier and taxonomy concept.
• Currency or other unit.
• Period start and end, where applicable.
• Filing date, form and accession number.
• Retrieval time and source location. Keep original observations separate from any selection policy. If a later filing repeats or revises an earlier figure, your system should explain which observation it selected.

3.Calculate Before Asking the Model to Explain

Use deterministic application logic for arithmetic. Give the language model the verified calculation and its inputs.

For example: Hypothetical annual revenue increasing from $100 million to $110 million represents 10% growth. That comparison works only when both observations cover comparable periods and use compatible units.

Add checks for missing values, zero denominators and mismatched periods. When a check fails, return an explicit unavailable result rather than an invented number.

These checks should run before an explanation reaches the user.

4. Retrieve Narrow Evidence

When the user asks about a business risk, retrieve relevant filing passages and retain their section labels and document links.

Ask the model to distinguish reported facts, interpretations and unanswered questions. Require each factual claim to point to supplied evidence.

Then validate those references. A citation-shaped string is insufficient: the referenced passage must actually support the statement. For high-impact conclusions, retain human review.

5. Make Uncertainty Visible

Display the reporting period beside each result. Separate a historical number from a forecast, and identify assumptions behind generated interpretations.

An assistant can describe falling margins without claiming that a business is doomed. It can identify missing information without filling the gap with confident prose.

For background on interpreting company decisions, I publish investing explainers at BetterThisWorldStocks, which I run. These explanations provide reader context; filings remain the evidence for company-specific claims.

Build for Review

Keep a backend ingestion layer: the SEC states that does not support CORS. Follow its current automated-access guidance, cache responses and avoid unnecessary repeated downloads.

The first milestone should be a traceable answer to one narrow question. A small tool that shows its evidence is easier to improve than a broad assistant whose conclusions nobody can reproduce.

Suggested Hashnode tags: Artificial Intelligence, Data Engineering, APIs, Fintech.