SERVER-AUTHORITATIVE CHECKOUT

Build the order first. Then ask for payment.

The customer's browser can display a checkout, but it must never choose the merchant recipient, amount, reference, or paid state.

1. Create the authoritative order tuple

Generate a unique order reference on your backend and store the expected recipient, exact amount, and confirmation policy before returning anything to browser JavaScript.

Merchant state

reference: order_8f42d1
recipient: pbe1YOUR_MERCHANT_ADDRESS
amount: 25.00000000 PBE
confirmations: 12

2. Ask a PBE node for a payment request

Shell

curl -X POST https://paybyte.org/rpc/commerce/payment-request \
  -H "Content-Type: application/json" \
  -d '{"recipient":"pbe1YOUR_MERCHANT_ADDRESS","amount":"25","reference":"order_8f42d1","label":"Example Store","confirmations":12}'

The returned payment URI or wallet handoff is a transport mechanism. It does not replace the order tuple stored by your backend.

3. Verify from the server

Shell

curl "https://paybyte.org/rpc/commerce/payment/order_8f42d1?recipient=pbe1YOUR_MERCHANT_ADDRESS&amount=25&confirmations=12"

Only the backend should decide that an order is paid. Require the same reference, recipient and exact amount that were stored when the order was created.

4. Fulfil exactly once

Lock or atomically update the order, verify it has not already been fulfilled, mark it paid, perform the grant/shipment action, and commit. Repeated polling or repeated webhook delivery must not duplicate fulfilment.

Confirmation depth is confidence, not hard finalityPBE 0.0.1 uses canonical-chain confirmation depth and reports hardFinality=false. Define a confirmation policy appropriate to your own settlement risk.

For exact request and response schemas, continue to the Commerce API reference.