Security and credential boundaries
Define who holds credentials, how events are trusted and what must be reviewed before production.
Map your integration boundaries
Recommended design review: draw the browser, your server, the gateway and any event receiver separately. Assign each credential and data type to one boundary. The public tokenization key can identify the frontend integration; the private payment key belongs only on your server. online
Keep merchant access explicit
Use your application permissions to decide which tenant and operator may initiate or reverse a payment. A valid gateway credential is not a substitute for checking that a user may act on a particular order. Resolve the merchant from trusted server-side account context. Load the order under that merchant and verify the user’s role. Calculate the payable amount from the server order record. Redact credentials and sensitive payment information from logs.
Verify the correct event contract
Gateway transaction notifications and Merchant Sign-Up notifications use different signature headers and signed messages. Route each event family to its matching verifier and secret. Parse and apply the payload only after authenticity checks pass. Event family Verification reference in this portal Payment gateway Gateway webhooks: nonce plus raw body signing contract. Merchant onboarding Sign-Up webhooks: raw JSON subscription-secret contract.
Review production responsibilities
Tokenized collection reduces exposure to raw payment data but does not determine your complete PCI responsibilities. Agree ownership of access reviews, secret rotation, incident response and security assessment before launch. This is an implementation checklist, not a certification of the software. The portal contains documentation examples only. It does not validate PCI compliance, protect a live backend or establish merchant feature activation.