Where the split of responsibility sits
Adyen documents the cryptography: what a JWE is, which algorithm to use, how to structure the encrypted payload. Their guide is the authority on this — see Card encryption with JWE.
Forge provides the values specific to your store: your API key, store ID, and Public key.
Your own engineers write the code that connects the two.
This collection exists in the gap between those — it doesn't replace Adyen's documentation, and SwipeAras doesn't write or maintain your integration code. The articles from here on are worked examples showing how the pieces fit together, so your engineers aren't starting from a blank page.
What happens where
Encryption happens in the browser, before anything reaches your server:
The shopper enters card details into your own form.
Your JavaScript encrypts those details using your store's Public key, producing a single encrypted value (a JWE).
Your form submits that encrypted value — never the raw card details — to your backend.
Your backend includes it in a payment request as
paymentMethod.encryptedCard.
Steps 1–2 are what the rest of this section covers. Steps 3–4 are your normal application flow — nothing about them changes because the card data happens to be encrypted.
What you actually need to build
Adyen's guide walks through encrypting card details once you already have a JWK (a specific JSON format for a public key). The one gap their guide doesn't cover — because it's specific to how Forge exposes your key — is turning your Public key string into that JWK. That conversion is what the next two articles cover:
What is
jose, and why does Adyen's guide use it? — background on the library Adyen's own documentation uses as its exampleExample: converting your Public key into a JWK (TypeScript) — a worked, illustrative example of that conversion
Reference
Adyen: Card encryption with JWE — see particularly "Compute your JWK" and "Encrypt card details"
Adyen: Checkout API
/paymentsreference