Skip to content

fix(checkout): surface Transak order status on sale SALE_SUCCESS event - #2951

Draft
allan-almeida-imtbl wants to merge 2 commits into
mainfrom
allanalmeida/checkout-sale-success-status
Draft

allan-almeida-imtbl wants to merge 2 commits into
mainfrom
allanalmeida/checkout-sale-success-status

Conversation

@allan-almeida-imtbl

Copy link
Copy Markdown
Contributor

Problem

The sale widget's card path emits SALE_SUCCESS as soon as Transak reports PROCESSING — the card payment is captured but the mint has not settled yet (settlement takes ~2–3 min). The host payload is { paymentMethod, transactions, tokenIds, transactionId } with no field to distinguish PROCESSING from COMPLETED, so integrators are told "success" while the order is still processing and can't tell the two apart.

Root cause in widgets/sale/views/PayWithCard.tsx:

  • onOrderCompleted is wired to the same handler as onOrderProcessing, so the success path fires on TRANSAK_ORDER_SUCCESSFUL + status PROCESSING.
  • The handler builds a details object that already contains orderStatus, but only details.transactionId is forwarded — orderStatus is dropped before the event.

Change (additive, non-breaking)

  • Add an optional status field to the public SaleSuccess event type (checkout-sdk).
  • Thread the real Transak order status through useSaleEvents.sendSuccessEventSaleWidgetEvents.sendSaleSuccessEvent → the host SALE_SUCCESS payload.

Integrators can branch on status ('PROCESSING' vs 'COMPLETED') and reconcile settlement server-side via transactionId. Crypto payments (synchronous) leave status undefined, so existing consumers are unaffected.

Not in scope (separate, breaking)

Does not change when success fires or the auto-close-on-PROCESSING behaviour — those alter existing semantics and need their own breaking change / product decision. This PR is the minimal, backward-compatible unblock.

Impact

The premature-success behaviour affects every live card-checkout integrator, not just one — e.g. Ubisoft/Fates, Chess Universe, Gods Unchained, TokenTrove, Striker Manager (per checkout analytics).

Tests

checkout-sdk typecheck passes; checkout-widgets typecheck clean. No behavioural change to existing flows.

🤖 Generated with Claude Code

allan-almeida-imtbl and others added 2 commits September 8, 2026 14:23
The sale widget card path emits SALE_SUCCESS as soon as Transak reports
PROCESSING (payment captured, mint not yet settled — typically a couple of
minutes). The host payload was {paymentMethod, transactions, tokenIds,
transactionId} with no field to tell PROCESSING from COMPLETED; the handler
already builds orderStatus but only forwarded transactionId.

Add an optional `status` field to the SaleSuccess event payload and thread the
Transak order status through sendSuccessEvent -> sendSaleSuccessEvent, so
integrators can distinguish a still-processing sale from a settled one and
reconcile settlement server-side using transactionId. Additive and backward
compatible (crypto payments, which settle synchronously, leave status undefined).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@nx-cloud

nx-cloud Bot commented Sep 8, 2026

Copy link
Copy Markdown

View your CI Pipeline Execution ↗ for commit 84c1ba4

Command Status Duration Result
nx affected -t build,test ✅ Succeeded 1m 25s View ↗

💡 Verify your cache is correct by running tasks in a sandbox. Read docs ↗


☁️ Nx Cloud last updated this comment at 2026-09-08 06:17:15 UTC

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant