Secure Sensitive Data
By the end of this lesson, you'll be able to:
- Explain why a raw card number should never be stored or logged
- Use a payment token instead of raw card details
- Apply Module 28's security discipline to genuinely sensitive financial data
Prerequisites: "Handle Declines and Retries"
Why "never store a raw card number" is non-negotiable
// NEVER DO THIS
Order__c order = new Order__c(Credit_Card_Number__c = '4111111111111111');
Storing a raw card number in Salesforce (or anywhere in Apex code, debug logs, or custom fields) creates enormous compliance exposure (PCI-DSS, the payment card industry's security standard) and genuine risk if that data were ever exposed. This isn't a "nice to have" security practice — it's close to an industry-standard hard requirement.
Using a token instead
// The card details never reach Salesforce at all — a client-side
// payment form (outside this course's scope) tokenizes the card
// directly with the gateway, and only THIS is passed to Apex:
String paymentToken = 'tok_1a2b3c4d5e6f';
PaymentResult result = new PaymentGatewayService().charge(amount, paymentToken);
Payment_Token__c (referenced back in Lesson 3's trigger handler) is exactly this — a one-time, single-use reference the gateway itself generates, meaningless to anyone who might see it, and useless for actually charging a different amount or account. The raw card number never reaches Salesforce, Apex, or a debug log at any point in this entire feature.
Applying Module 28's checks to this specific field
if (! Schema.sObjectType.Order__c.fields.Payment_Token__c.isAccessible()) {
throw new PaymentException('Insufficient permissions to process payment.');
}
Even Payment_Token__c itself — not the raw card number, but still sensitive — deserves the field-level security check from Module 28's CRUD/FLS lesson, restricting who can even read it, on top of never storing the far more sensitive raw card data in the first place.
Exercise
As a comment, explain why a payment token is safe to pass around and store, while a raw card number never is.
Show hint
Think about what each one can actually be used for if exposed.
Secure Sensitive Data Quiz
My Notes
Log in to keep private notes on this lesson.
Questions about this lesson
No questions yet — be the first to ask.
Log in to ask a question about this lesson.
Summary
This lesson makes explicit a design decision quietly present since Lesson 2: this feature never touches a raw card number at all, using a payment token instead — the single most important security decision in the whole project.