After payment succeeds: turn every payment into a completed service
The payment arrived. Why is the customer waiting?
A customer pays 100 USDT for a membership. Checkout says paid, but access remains inactive. The interruption could be in notification delivery, order matching or entitlement activation. The customer still needs a completed service.
Track three separate outcomes: payment confirmed, notification reliably received, and service delivered. These records help support explain progress and let the system resume interrupted work.
Separate payment from fulfillment
Payment status describes the payment result. Fulfillment status describes account credit, membership activation or delivery. Keep separate states and timestamps instead of using one success flag for everything.
If membership activation fails after confirmed payment, show “Paid, activation processing.” Preserve the payment result and the pending task. Do not revert to awaiting payment or ask the customer to pay again.
Receive reliably before delivering
Verify signatures according to the UUGate API documentation, then validate order ownership, asset, network, amount and status. A browser redirect or transfer screenshot cannot replace server-side verification.
Persist the validated event and pending task before acknowledging it as documented. Slower delivery can run in a subsequent job. An event held only in memory may disappear after a restart, even if the sender received a success response.
One order, one business outcome
Notifications can arrive more than once. Use a unique constraint combining merchant and order identity, together with transactions or conditional updates, to prevent duplicate credits, deliveries or membership extensions.
For external services, reuse a stable idempotency identifier and retain their response. A timeout does not prove failure: check the previous result or use the service's idempotency mechanism before trying again.
Give exceptions a next step
Maintain a searchable list of paid but unfulfilled orders, including the last error, attempt time and result. Separate temporary failures from mismatched orders or amounts that need review.
Connect platform order numbers, merchant order numbers, transaction hashes and delivery records. Manual recovery should use the same deduplication and audit process. Reconcile actual on-chain wallet balances and the separate fee account independently; fulfillment records are not balance authority.
Test interruptions before launch
- A normal payment delivers the service once.
- Duplicate notifications do not duplicate credits or deliveries.
- Saved tasks survive a service restart.
- External timeouts can be resolved without duplicate fulfillment.
- Confirmed payments with failed delivery show a processing state and a way to check progress.
UUGate supplies payment and notification capabilities; the merchant application turns verified results into its own service. Acceptance testing should end only when the customer receives that service.
UUGate API documentation · Webhook recovery guide
General event-handling reference: Stripe webhook documentation. Use UUGate documentation for UUGate signatures, fields and acknowledgment requirements.