Keep booking and payment records in sync.

The money rule is defined elsewhere. This sequence follows its result across booking, checkout, gateway, point of sale, invoice, receipt, refund, export, and incident records.

1. 1
   Define the integration contract

   Name the booking, checkout, gateway, POS, invoice, receipt, refund, accounting, and export systems; record which one owns each state and which current support or geographic source applies.

2. 2
   Create the identity map

   Assign durable references for the booking, obligation, order or invoice, payment attempt, successful transaction, refund, event, and receipt before exchanging status.

3. 3
   Translate every state

   Map initialized, pending, authorized, captured, succeeded, failed, cancelled, voided, refunded, booked, and missing states without treating unlike labels as equivalent.

4. 4
   Make commands and events replay-safe

   Reuse one logical operation key for uncertain retries, verify incoming events, record processed event identities, and expect delayed, repeated, or out-of-order delivery.

5. 5
   Project changes across systems

   Carry booking edits, checkout actions, offline POS payments, invoice updates, discounts, tax or tip outputs, voids, refunds, and failures to every dependent record without overwriting history.

6. 6
   Reconcile and recover

   Compare booking, payment, order, POS, invoice, refund, receipt, export, and incident records; close only when the final state agrees or a named limitation remains visible.

Booking-led, commerce-led, gateway-led, point-of-sale-led, invoice-led, and custom event routes have different authoritative states and recovery burdens.

Each step has a different authoritative owner. Preserve the shared identities while commands, events, offline actions, and later changes move at different speeds.

1. 1
   Create the obligation

   Booking and money-rule owner: Create BOOKING-A and OBLIGATION-A with currency and links to the price, deposit, discount, tax, tip, invoice, and refund policies owned elsewhere.

2. 2
   Initialize checkout

   Booking, commerce, or gateway: Create ORDER-A or INVOICE-A and ATTEMPT-A once; preserve the logical operation key, amount, currency, and booking reference.

3. 3
   Record the payment result

   Gateway or POS: Distinguish pending, authorized, captured, succeeded, failed, cancelled, voided, and refunded outcomes; do not infer settlement from navigation.

4. 4
   Project the result

   Integration boundary: Update the booking, order, invoice, receipt, staff checkout, and customer view from the authoritative result without duplicating the transaction.

5. 5
   Propagate later changes

   Change and integration owners: Carry reschedules, cancellations, price changes, offline POS actions, retries, disputes, voids, and refunds as linked events rather than replacements.

6. 6
   Reconcile and recover

   Named operator: Retrieve final records, compare identities and states, repair the first broken edge, preserve the incident, and close only one explainable outcome.

Pending payments, duplicate events, point-of-sale-originating actions, booking edits, refunds, and geographic changes each need an explicit propagation and recovery rule.

Force missing confirmation, a timeout, a duplicate event, an offline point-of-sale payment, a later refund, and an unsupported route. Watch whether the system recovers without guessing or charging twice.

A logo, installed plugin, or successful happy path is not enough. Use one fixed synthetic manifest to observe which system owns each state, how retries and events behave, and whether every record reaches one final answer.

1. 1
   Create an offline test manifest with BOOKING-A, OBLIGATION-A, ORDER-A, ATTEMPT-A, PAYMENT-A, EVENT-A, INVOICE-A, RECEIPT-A, and REFUND-A; record expected state translations and stable links.
2. 2
   In an explicitly authorized sandbox only, rehearse pending, failed, successful, duplicate, out-of-order, offline-POS, price-change, cancellation, void, and refund paths without real customers or payment methods.
3. 3
   Compare the booking, customer view, staff checkout, gateway or POS, order or invoice, refund, receipt, export, and incident log; keep every mismatch and unavailable capability Unknown.

Keep the test fair

• Use only synthetic identities and documented test modes after account, integration, and write authorization is explicit.
• Record exact product, plan, seller country, currency, payment method, integration version, checked date, operation keys, event IDs, statuses, timestamps, and limitations.
• Treat this checker and guide as a product-neutral test plan, not evidence that a named product, gateway, POS, geography, tax rule, or integration is supported or suitable.