Cross-Border QR Merchant Acceptance

Governed merchant-close workflow from QR presentation through settlement posting, batch admission, merchant reporting, and evidence close.

Cross-border QR merchant acceptance

The full lane from payer action to merchant-close certainty, with immediate result, settlement posting, batch admission, merchant reporting, adjustment handling, reconciliation, and evidence publication as distinct governed steps.

StableNexus normalizes outputs from the acceptance participant, the settlement participant, and the reconciliation service into one operating record so merchant-presented QR close stays readable end to end.

Actor-lane operating map

Seven actors on one normalized lane.

Each actor owns one boundary; StableNexus normalizes the handoffs into one readable merchant-close workflow.

Canonical chapters

ChapterOutcomeLifecycle states
Corridor scope and readinessCorridor participants, scope, and readiness controls are defined.corridor_ready
Scheme linkage and settlement policyScheme linkage, merchant acceptance controls, and settlement policy are established.route_bound
Payment submission and immediate resultThe QR payment is submitted and an immediate result is returned.payment_submitted, payment_accepted, payment_rejected
Settlement posting and batch admissionSettlement posting is recorded and batch admission status is visible.settlement_posting_pending, settlement_posted, batch_admission_pending, batch_admitted, adjustment_required
Merchant reporting and close windowMerchant reporting is published and close-window state is available.report_published, close_window_open
Refund, reconciliation, and evidence closeRefund handling, reconciliation, and evidence close are completed.refund_open, reconciliation_signed, evidence_published

Phase map

How the six chapters sequence.

Lifecycle states

Settlement posting, batch admission, reporting, and evidence close stay distinct.

Artifact and evidence matrix

ChapterRuntime artifactsDocs-derived surfaces
Corridor scope and readinessparticipant_readiness_snapshotreadiness_packet
Scheme linkage and settlement policymerchant_acceptance_profile, scheme_linkage_snapshotsettlement_policy_state
Payment submission and immediate resultqr_transaction_tracepayment_trace
Settlement posting and batch admissionsettlement_posting_snapshotposting_reference, batch_admission_state | Evidence: settlement_posting_reference, batch_admission_snapshot
Merchant reporting and close windowmerchant_settlement_reportmerchant_report_packet, close_window_state
Refund, reconciliation, and evidence closerefund_or_dispute_log, reconciliation_close_packrefund_case_state, reconciliation_signoff_state

Control overlay matrix

OverlayActive in chaptersPurpose
Callback policyScheme linkage and settlement policy; Payment submission and immediate result; Settlement posting and batch admissionControl overlay across active chapters
Signed acknowledgmentScheme linkage and settlement policy; Payment submission and immediate result; Settlement posting and batch admissionControl overlay across active chapters
Poll fallbackScheme linkage and settlement policy; Payment submission and immediate result; Settlement posting and batch admissionControl overlay across active chapters
Status inquiryScheme linkage and settlement policy; Payment submission and immediate result; Settlement posting and batch admissionControl overlay across active chapters
Idempotent recoveryScheme linkage and settlement policy; Payment submission and immediate result; Settlement posting and batch admissionControl overlay across active chapters

Technical closeout sequence

From immediate result through posting, batch, reporting, refund, and evidence close.

Support docs

Boundary

This page is the specification surface. Interactive cases and the projector are the proof surfaces. The operator workspace is the execution surface.