Transaction Protection & Escrow

Protected transaction status

A transaction should only display a protected or escrow-style status when the payment and protection workflow actually confirms that state. Gadget Trade must not describe an ordinary seller payment as escrow merely because an order has been created.

Protection lifecycle

1. 1Order created — the buyer has submitted an order.
2. 2Payment confirmed — the configured payment provider has confirmed payment.
3. 3Protection active — the transaction meets the requirements for the supported protection flow.
4. 4Delivery verified — the delivery or handoff event has been recorded.
5. 5Release or refund — the transaction reaches a defined release or refund state.
6. 6Dispute — a protected transaction can be paused for evidence review where the applicable workflow permits it.

Evidence and release

A release decision should be based on the transaction record, delivery status, applicable protection rules and any open dispute. The platform should record protection events so support and authorised administrators can understand what happened without relying on screenshots.

Payment-provider boundary

Payment processing, regulated custody and insurance are separate services. Gadget Trade only describes a payment as protected, held or insured when the relevant provider or operational workflow has actually confirmed that service. Users can see the transaction state presented in their order flow.

Off-platform payments

Payments requested outside the official transaction flow may not receive the protections associated with the supported Gadget Trade order flow. Users should keep the transaction on the official platform whenever the feature is available.