Security and compliance boundaries
Secret keys are server-only
Section titled “Secret keys are server-only”Merchant and channel API keys authorize money movement and merchant operations. Keep them in server-side secret storage. Never place them in browser JavaScript, mobile packages, HTML, URLs, client logs, analytics, or support screenshots. Buyer-safe checkout calls use the checkout-session capability and must not be “helped” by adding an API key from the browser.
Allowed origins
Section titled “Allowed origins”allowed_origins constrains merchant-hosted checkout. Register the exact HTTPS
origins that run embedded or direct checkout, separate sandbox from live, and
remove origins that no longer host it. An origin header is a browser security
signal; it is not a substitute for API-key authorization on a server.
Content Security Policy
Section titled “Content Security Policy”Build CSP from the resources the deployed checkout actually uses. The Maxana
entries begin with the selected API origin (https://staging.api.maxanapay.com or
https://api.maxanapay.com). Add only the provider script, frame, image,
and connection origins exercised by the chosen rail. Test the enforced policy in
sandbox, monitor violation reports, and avoid broad wildcards or unsafe-eval
as shortcuts.
The published major-1 SDK contract uses this compatibility ceiling. Include the SDK source only on pages that mount it:
script-src https://js.maxanapay.com https://www.paypal.com https://*.paypal.com https://*.paypalobjects.com https://*.venmo.com https://pay.google.com https://applepay.cdn-apple.com;
connect-src https://api.maxanapay.com https://staging.api.maxanapay.com https://*.paypal.com https://c.paypal.com https://*.stats.paypal.com https://pay.google.com https://google.com https://*.google.com https://applepay.cdn-apple.com;
frame-src https://www.paypal.com https://*.paypal.com https://*.venmo.com https://pay.google.com;
img-src data: https://*.paypal.com https://*.paypalobjects.com https://*.venmo.com https://*.stats.paypal.com https://*.gstatic.com https://pay.google.com https://applepay.cdn-apple.com;The sandbox entry is the one exception, and it is the only one. It names a
Maxana test deployment rather than a third party’s service, so a compatible
release may move it; the live origin does not move within the major. It has
moved once. A sandbox page whose connect-src still names an
earlier Maxana test origin has to add https://staging.api.maxanapay.com, or
the buttons render while the browser blocks every call behind them. Live pages
allow https://api.maxanapay.com and are unaffected.
The current contract reserves PayPal, Google Pay, Apple Pay, and Venmo origins, alongside the Maxana ones above, so the third-party list does not grow within the major. This is a compatibility boundary, not evidence that every funding surface is available. Remove unused origins from the policy you deploy and re-verify the policy whenever the production integration changes. Third-party scripts can change their own downstream requests; treat a newly required origin as an incident rather than silently weakening CSP.
PCI boundary
Section titled “PCI boundary”Do not collect, log, proxy, or persist raw card numbers or security codes in your systems. Use the provider-hosted or tokenized fields supplied by the chosen checkout rail. Hosted or embedded presentation can change which systems touch card data, but it does not by itself determine a merchant’s PCI scope or SAQ. Have a qualified assessor confirm the final architecture and operating controls.
Webhooks and data handling
Section titled “Webhooks and data handling”Verify Maxana-Signature against the exact raw body
within its 300-second replay
window before parsing it into a trusted business event. Use a
timing-safe comparison, rotate secrets
deliberately, and make handlers safe for replay and reordering. Minimize stored
buyer data, restrict access, redact logs, and retain audit links between your
order and Maxana identifiers.
Current limits
Section titled “Current limits”Allowed origins and CSP are browser controls, not substitutes for server-side authorization. No secret key belongs in a buyer surface, and the documented SDK CSP ceiling does not mean every reserved payment capability is available.