Two buyers can open checkout for the last item before either payment is confirmed. A gateway tracks payment orders, but your store still needs an inventory policy. Trust Gateway does not replace your stock database or guarantee item availability. This guide describes a reservation workflow to implement in your merchant backend.
Reserve inventory before offering payment
Use a database transaction to confirm that sufficient stock remains and reserve the required quantity. Store a reservation identifier and expiry against the local purchase. Checking availability and subtracting later in an unrelated request leaves a race between buyers. The availability check and reservation update must be atomic.
For individually numbered goods or licence keys, reserve a specific available unit with a uniqueness constraint. For pooled stock, use a conditional update or equivalent protection that cannot reduce available inventory below zero. A checkout URL itself does not act as an inventory lock.
Connect the reservation to a gateway order
Once inventory is reserved, create the Trust Gateway order from your server. Save its ID, requested amount, payable amount and returned expiry beside the reservation. Define how long the reservation remains held when payment outcome is uncertain. Use the actual returned expiry rather than inventing an unrelated browser timer.
If creation fails definitively without creating an order, your store can release the reservation. If the network times out and the result is unknown, mark the attempt for review instead of immediately issuing another payment request. An order may exist even though the HTTP response never reached your application.
Allocate stock after verified payment
When authenticated status confirms the saved order as paid, compare its exact payable amount and lock the local purchase. Convert the reservation into an allocated sale and create one fulfilment task in your store's transaction. Use a unique gateway reference to stop duplicate callbacks or repeated checks from allocating additional stock.
Keep payment and fulfilment as separate states. A paid purchase can still be awaiting packing, delivery or inventory review. Do not change it back to unpaid because a downstream worker failed. The payment lifecycle guide explains gateway states; inventory state is an additional concern in your application.
Handle release and late confirmation
A timer reaching zero tells the customer to stop using that checkout; it is not proof that no transfer was initiated. Check the original order before releasing stock. A receiving route may still be awaiting confirmation after the visible payment window ends. Set a bounded review policy informed by current order status and receiving-side evidence.
If a reservation has been released and payment is later confirmed, place the purchase in an exception queue. Tell the buyer what happened and apply your published resolution policy. Do not silently substitute a product, allocate stock you no longer hold or promise an automatic refund that your operational process cannot provide.
Preserve the agreed price
Catalogue prices can change while customers pay. Save product description, quantity and agreed price at creation together with the gateway's requested and payable amounts. Verify against that snapshot rather than today's catalogue price. Calculate discounts on the server and show the exact payable total before payment.
Test the final-unit scenario
- Two buyers try to reserve the final unit simultaneously.
- A customer abandons checkout and reaches reservation review time.
- A confirmed payment event arrives twice.
- Payment is confirmed after a reservation was released.
- The catalogue price changes during checkout.
- A delivery worker fails after allocation.
For every case, verify inventory and payment state separately. Retain a history explaining when stock was held, released or allocated. Use the support evidence checklist to locate the original order and include unresolved purchases in daily reconciliation.