Error decision trees

1. 01

   Check status code

   409 means the app should change state; 5xx means retryable infrastructure or processor availability.

2. 02

   Inspect error code

   Branch on stable error code, not message copy.

3. 03

   Show calm user copy

   Avoid processor internals unless the user is in ATM settings or support tooling.

4. 04

   Log developer context

   Keep payment id, app order id, environment, and delivery id for support.

1. 01

   Call payout status before UI

   Do not show active checkout buttons for non-payable recipients.

2. 02

   Creator path

   Show setup or resolve-payment-state CTA.

3. 03

   Buyer path

   Show that this creator cannot receive payments yet.

4. 04

   Retry path

   Retry status after setup completes or support repairs account access.

1. 01

   Refresh availability

   Treat availability as an estimate until a hold succeeds.

2. 02

   Hold fails

   Show sold out or ask the buyer to choose a lower quantity.

3. 03

   Hold expires

   Create a new hold; never reuse an expired checkout.

4. 04

   Refund/void

   Void issued tickets or pass tokens if payment reverses.

• Confirm buyerDid matches assertion issuer.
• Confirm audience is ATM and lxm is the expected method.
• Confirm expiry and jti replay state.
• Fall back to guest-style checkout only when the app can still fulfill safely.
• Ask the buyer to refresh/re-auth in the originating app if identity matters.

1. 01

   Verify endpoint health

   Fix DNS, TLS, route, and raw body handling first.

2. 02

   Check signature

   Use the environment-specific secret and the raw body bytes.

3. 03

   Return success for duplicates

   A redriven event should not fulfill twice.

4. 04

   Redrive from dashboard

   Use stored delivery status after the receiver is fixed.

Duplicate delivery is not an error if the original side effect already succeeded. Store delivery ids before side effects and return success for duplicate deliveries after confirming state.