Skip to content

Security and compliance boundaries

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 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.

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:

Content Security Policy ceiling for major 1
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.

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.

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.

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.