data:
Which endpoints are encrypted
GET endpoints — List banks,
Fetch a payment link,
List refunds,
List chargebacks and
Ping — take no body at all.
Track an event is the one endpoint whose envelope key is
capitalised:
{"Data": "..."}, not {"data": "..."}.The key format
Your public encryption key arrives as a single base64 string. Decoded, it looks like this:
So the procedure is always: base64-decode the key → split on
! → take the second half → parse
the XML → base64-decode Modulus and Exponent → build an RSA public key from them.
The algorithm
Code
- JavaScript
- Python
- PHP
- Java
Requires
node-forge.encrypt.js
The sandbox encryption helper
While you are building, sandbox exposes an endpoint that encrypts a payload for you, so you can exercise the API before your own encryption code works.api-key header:
data from the response and send it as the data field of the real endpoint.
Older integrations may reference
/data/encrypt or /payment/data/encrypt. Both are
superseded — use /charge/data/encrypt.Troubleshooting
400 — Something went wrong while trying to decrypt your payload
400 — Something went wrong while trying to decrypt your payload
data string could not be decrypted. Usual causes: the wrong padding (OAEP instead of
PKCS#1 v1.5), a key that belongs to a different environment, encrypting the raw bytes
instead of base64-encoding the ciphertext, or a payload longer than the key can encrypt in
one block.The ciphertext is a different length every time
The ciphertext is a different length every time
That is expected. PKCS#1 v1.5 padding includes random bytes, so encrypting the same payload
twice produces different ciphertext. Both decrypt correctly.
Should I encrypt on the client or the server?
Should I encrypt on the client or the server?
The server. Even though the key is public, doing it server-side keeps card data off your
own frontend and out of your logs, and avoids shipping an RSA implementation to the browser.