Security and Compliance¶
This page is for compliance officers, security reviewers and administrators evaluating ChargeOn. It covers what ChargeOn keeps about a card, what it encrypts, how your choice of checkout affects your PCI obligations, where 3D Secure runs, and who can act on payment data.
It describes how the product behaves. It is not a compliance certification, and how the standards apply to your organisation depends on your own configuration and environment.
What ChargeOn Keeps About a Card¶
ChargeOn does not write full card numbers or CVV codes to your Salesforce org's database.
| Kept | Never kept |
|---|---|
| The last four digits, for receipts and display | The full card number |
| The expiry date, for card management | The CVV code |
| A token from the gateway that stands in for the card | The token in plain text; ChargeOn stores it encrypted |
On some gateways the customer completes payment on the gateway's own page, and the gateway stores the payment method instead of ChargeOn. The card type, expiry date and last four digits may then not be known in Salesforce. See save a payment method.
Requirements for the customer's browser
If your organisation has specific requirements for how card data is handled in the customer's browser, confirm them with whoever implemented ChargeOn for you before go-live.
What ChargeOn Encrypts¶
ChargeOn encrypts the following with AES-256 before storing them:
- Gateway credentials, encrypted automatically when you save a gateway
- Gateway customer profiles
- Saved payment method tokens
- Transaction authorisation codes
The key is generated at random when ChargeOn is installed and held in the package's protected configuration, which your administrators cannot read directly. Credentials are decrypted only in memory, only for the call to the gateway, and are never shown to a customer or sent to a browser.
Some data is stored without ChargeOn's encryption:
| Data | Why |
|---|---|
| Last four digits and expiry date | Kept for receipts and card management; neither can be used to take a payment |
| Billing address | Not cardholder data under PCI DSS. It is personal data, protected by your org's standard Salesforce security |
| BIN lookup API key, if you use one | Used only to tell credit cards from debit cards for surcharge rules. Held in a restricted configuration setting; it cannot move money or reveal card data |
Rotating the Key¶
Rotating the key needs the Manage Encryption Keys permission. It is included in the ChargeOn Admin and ChargeOn Implementation Admin permission sets, so by default everyone who holds either set can rotate the key. Review who holds them.
Rotations are at least 24 hours apart and cannot overlap. ChargeOn re-encrypts existing records in the background and keeps older keys, so no record becomes unreadable. See rotate the encryption key.
How Checkout Affects Your PCI Scope¶
Each gateway record has a Checkout Experience, which decides where the customer types their card details. It is the setting with the largest effect on your PCI obligations.
| Checkout experience | Where card details go | Effect on your PCI scope |
|---|---|---|
| ChargeOn's own payment page | Entered on ChargeOn's page and held in memory only while the gateway processes the payment | Card data passes through your environment |
| The gateway's embedded field | Typed into a field the gateway controls; ChargeOn receives a one-time token instead | Card data does not reach ChargeOn or your org |
| The gateway's own checkout page | The customer leaves ChargeOn and pays on the gateway's page | Card data does not touch a ChargeOn page at all |
Customers pay on the gateway's own checkout page with Adyen, PayPal and Stripe, and RazorPay uses its own checkout flow. See the gateway reference. The same checkout choices apply to payment links.
How much your scope shrinks is decided with your own PCI assessor, based on your wider environment.
Two trade-offs of keeping card data off ChargeOn
The gateway's embedded field needs the gateway's secure domains allow-listed in your org. Your implementation team does this after installation; it is not automatic. The gateway's own checkout page needs no such step.
When card details never reach ChargeOn, ChargeOn cannot retry a declined payment on a backup gateway. See route payments between gateways.
Do not change Checkout Experience yourself. Raise it with whoever implemented ChargeOn for you, as connect a payment gateway explains.
3D Secure¶
3D Secure is an identity check the card issuer runs at the moment of payment. It is how Strong Customer Authentication (SCA) is applied to card payments under PSD2 in Europe. Support depends on the gateway.
| Gateway | How 3D Secure runs |
|---|---|
| Adyen, Stripe, Checkout.com | ChargeOn runs the check and confirms the result, without the customer leaving the page |
| Global Payment | The customer stays on the page; the gateway's own window runs the check and confirms the result |
| Braintree, Shift4 | Runs automatically inside the gateway's own field |
| Elavon, FatZebra | Runs once you switch it on with the gateway directly |
| Other gateways | Not available through ChargeOn's embedded checkout. Use one of the gateways above, or the gateway's own checkout page, where the gateway applies 3D Secure itself |
3D Secure does not run in every payment flow
ChargeOn's in-page 3D Secure check does not run by default when a card is entered outside a payment link, for example when your team saves a card for a customer without charging it. If your organisation needs 3D Secure in specific flows, including cards customers save in the portal, confirm the behaviour with your implementation team before go-live.
Phone and Mail Orders¶
A card your team keys in for a customer over the phone or by post is a mail order or telephone order (MOTO) payment. Under PSD2, MOTO payments are out of scope of Strong Customer Authentication.
An administrator can switch on MOTO classification for each gateway. ChargeOn then marks staff-keyed charges and authorisations as MOTO, so the gateway and the card issuer do not ask for 3D Secure. It never applies to a customer paying their own payment link or updating their own card.
Who Can Act on Payment Data¶
ChargeOn's payment actions, such as charging, refunding, editing gateway credentials and rotating the key, need the ChargeOn permission sets an administrator assigns. Grant them per role: a role can refund without being able to charge.
Which records a user can see follows your Salesforce sharing model. A user with the Salesforce View All Data or Modify All Data permission can read ChargeOn records, including transaction history, without any ChargeOn permission set. Review both when you set up access.
| Who | What they can reach |
|---|---|
| Your team in Salesforce | The actions their ChargeOn permission sets allow, on the records Salesforce sharing lets them see |
| A customer paying a payment link | Only the payment that link was issued for. They pay as a guest user, whose permissions must be kept narrow |
| A customer logged in to the portal | Only their own records, once you set up the Sharing Sets the portal setup describes. Without them, a customer sees nothing |
The AI Assistant¶
The AI assistant is optional. An operation runs only when both the agent's Allowed Operations and the user's own permission sets allow it, and within the spending ceilings your organisation sets. See the Agentforce setup guide.
- Card data: The assistant never asks for a card number and refers to saved methods by name, such as "the card ending 4242". Anything a user types into the chat is part of the conversation, so users must keep card numbers, CVVs and bank account numbers out of it.
- Confirmation: Before a payment, refund or schedule change, the assistant shows a preview and waits for the user to confirm in the conversation. The confirmation is a reply, not a time-limited hold on the transaction.
- Same checks: Every action the assistant starts runs through ChargeOn's payment engine, with the same checks as the same action taken from a Salesforce record.
Questions Not Answered Here¶
For a security questionnaire, or a requirement this page does not cover, contact whoever implemented ChargeOn for you before go-live.