TRUST BOUNDARIES
Assume the customer controls the browser.
DevTools, modified JavaScript, altered links, duplicate callbacks and reorganization events are normal conditions an internet-facing merchant integration must tolerate.
Browser boundary
- Do not accept recipient, amount, reference or paid state from the browser as authoritative.
- Do not expose webhook credentials or database credentials client-side.
- Use CSRF protection for merchant endpoints that create or mutate order state.
- Escape untrusted output and use a restrictive Content Security Policy.
Payment verification
- Store the expected reference, recipient and amount before asking the customer to pay.
- Verify all three values server-side against a compatible PBE node.
- Require the configured canonical confirmation depth.
- Do not interpret
confirmedas hard mathematical finality in PBE 0.0.1.
Fulfilment
- Make each order reference unique in the merchant database.
- Make fulfilment idempotent so repeated polling or webhook delivery cannot grant twice.
- Verify webhook HMAC over the exact raw body and reject stale timestamps.
- Define how a later
payment.reorgedevent affects already-fulfilled orders.
Client-side edits cannot satisfy a secure backendA customer may alter what their browser displays or which wallet link they personally open. That must not change the tuple stored by the merchant backend or cause an unrelated payment to be accepted.