Security and API versions

API versions

Send PayLynks-Version: 2026-10-21 to pin the API version your integration was built against. Without the header you get the latest version. Every /api/v1 response includes the PayLynks-Version that served it. Unknown versions are rejected with 400 api_version_invalid. Breaking changes ship as a new dated version; old dates keep working until retired with notice.

Card and bank data

Card and bank details are entered in Stripe's fields inside PayLynks checkout and go straight to the processor. PayLynks servers, databases and AI agents only ever see tokens.

Hosted payment pages (/pay, /i, /r, /sub, /give, /portal, /onboard, /embed) send a Content Security Policy that allows scripts and frames only from PayLynks and Stripe. Violations are reported and logged, so an unexpected script on a payment page is noticed (PCI DSS 6.4.3 and 11.6.1). Only the embeddable checkout can be framed; every other page refuses to load in a frame.

Gateway credentials

Merchants' processor keys are encrypted with AES-256-GCM before they're stored. The encryption key is held outside the database, and the table holding the encrypted keys can't be read through the public API.

Surcharge rules

Surcharge and dual-pricing rules are versioned data. Each payment records the rule version it was priced under (pricing_rules_version). PayLynks admins add new versions as drafts and activate them after review, so a change in law is a data update rather than a code deploy.

Webhooks and agents

Webhooks are signed (see Webhooks). AI agent connections are scoped and capped per call, can never receive secret keys, and every action is logged (see MCP server).