JourneyToCTA Diaries Part 11 - Data Governance

As organizations continue to operate in an increasingly regulated data landscape, customer privacy has become a foundational pillar of enterprise architecture. In the previous blog, we explored how major regulations such as the General Data Protection Regulation (GDPR), Health Insurance Portability and Accountability Act (HIPAA), and California Consumer Privacy Act (CCPA) shape the way Salesforce solutions must be designed to ensure compliance, security, and trust.

We examined how data residency requirements influence architectural decisions, and how organizations can leverage mechanisms such as adequacy decisions, Standard Contractual Clauses (SCCs), and Binding Corporate Rules (BCRs) to enable compliant cross-border data transfers without fundamentally altering where data is stored. This highlights the importance of aligning legal frameworks with technical architecture.

The blog also covered the role of encryption and data protection, emphasizing the use of Salesforce Shield to secure sensitive data through platform encryption, field-level encryption, and audit capabilities. A key takeaway was the need to balance security with usability by aligning encryption strategies to data classification.

In addition, we explored the importance of consent management, where organizations must capture and enforce granular, purpose-based user consent across all systems. Salesforce’s consent data model enables this level of control, ensuring that customer preferences are respected and auditable.

Finally, we discussed how to operationalize data subject rights through scalable handling of Data Subject Access Requests (DSARs). With the help of automation and tools like Privacy Center, organizations can efficiently manage access, deletion, and data portability requests while maintaining full auditability.

Together, these elements reinforce a “privacy by design” approach—embedding compliance into every layer of the Salesforce architecture. In the next blog, we will build on this foundation and dive deeper into how these principles translate into specific architectural patterns and real-world implementation strategies.

In this blog, we will focus on data governance considerations for payment scenarios and explore architectural patterns to address this common challenge, based on different system landscapes.

Payment transactions require a higher level of security due to the sensitive nature of the data involved. These scenarios are governed by the Payment Card Industry Data Security Standard (PCI DSS), which defines a comprehensive set of security standards for handling payment information. This includes the capture, processing, storage, and transmission of sensitive data such as credit card numbers, bank account details, and payment tokens (e.g., Stripe IDs).

Given these stringent requirements, architects must design solutions that minimize risk, reduce the scope of compliance, and ensure that sensitive payment data is handled in a secure and compliant manner across all systems involved.

PCI Compliance

There is a common misconception that Salesforce is not PCI compliant. In reality, Salesforce has consistently maintained Payment Card Industry Data Security Standard Level 1 certification—the highest level of compliance—for many years, with specific platform components undergoing regular certification updates. Detailed information on PCI DSS compliance across Salesforce services is publicly available here and should be reviewed as part of any architecture and compliance assessment.

Another widespread misunderstanding is that leveraging a PCI-compliant vendor automatically guarantees end-to-end compliance for the entire solution. This is not the case. PCI compliance is a shared responsibility model, and while Salesforce provides a compliant platform foundation, customers are responsible for ensuring that their implementation adheres to PCI requirements.

This includes properly configuring user access controls, enforcing least privilege, securing integrations, and implementing appropriate encryption and key management strategies. Additionally, architects must ensure that sensitive payment data is either avoided, tokenized, or securely handled in alignment with PCI guidelines. Failure to design and configure these controls correctly can expand the PCI scope and introduce compliance risks, even when using a certified platform.

Ultimately, achieving and maintaining PCI compliance in a Salesforce-based solution requires a combination of platform capabilities, sound architectural decisions, and strong operational governance.

Tokenization

Salesforce’s certification under the Payment Card Industry Data Security Standard as a data storage service provider means that a significant portion of the compliance burden is already addressed at the platform level. However, despite this strong foundation, it is generally considered a best practice to avoid storing raw credit card data directly within Salesforce fields. Instead, architects should adopt tokenization strategies to minimize risk and reduce the overall PCI scope.

Tokenization is not a native Salesforce security feature but rather a capability provided by payment gateways and processors. In this model, sensitive payment data—such as credit card numbers—is captured and stored securely by the payment provider. In return, the provider issues a unique token that represents the payment method. This token is then stored in Salesforce and used for subsequent transactions, ensuring that sensitive data never resides within the Salesforce environment.

By leveraging tokenization, organizations significantly reduce their liability and audit scope, as they are no longer storing primary account numbers (PANs) within their systems. Instead, the actual payment data is securely stored and encrypted within the payment gateway’s infrastructure. This approach aligns with key PCI principles, such as minimizing the storage of sensitive data and limiting the distribution of encryption keys across systems.

While tokenization introduces dependencies on the payment provider—since tokens are typically specific to a given gateway and cannot be reused across providers—it provides a strong security advantage. It ensures that even if Salesforce data is accessed, the tokens themselves are meaningless outside the context of the payment processor.

In practice, tokenization still preserves usability for business operations. For example, the last four digits of the credit card are typically retained and associated with the token, allowing customer service representatives to identify and confirm the correct payment method with customers. This provides a similar user experience to encrypted card storage, without exposing the full card number.

Overall, tokenization represents a critical architectural pattern for handling payment data in Salesforce, enabling secure processing while reducing compliance overhead and aligning with PCI best practices.

Payment Flow

The diagram illustrates a typical payment flow within a Salesforce-centric architecture, where a Payment App (built natively on Salesforce, via Salesforce Billing, or an AppExchange solution) initiates the transaction.

The payment request is first sent to the payment gateway, which plays a critical role in securely capturing and encrypting sensitive payment information, often performing tokenization to ensure that raw card data does not enter Salesforce systems.

The gateway then forwards the transaction to the payment processor, which is responsible for communicating with the banking networks to authorize and settle the payment with the customer’s bank. While the gateway focuses on secure data handling and integration, the processor handles the financial transaction lifecycle, including authorization, clearing, and settlement.

This separation of responsibilities is key to aligning with Payment Card Industry Data Security Standard requirements, reducing risk, and ensuring that sensitive payment data is managed within PCI-compliant systems.

Salesforce Payment Solution Patterns

The appropriate payment strategy should be selected based on the organization’s existing system landscape and payment capabilities. If the organization already has a payment gateway that supports a hosted payment page, a hosted payment strategy is often preferred, as it ensures that sensitive payment data is captured directly by the gateway, keeping Salesforce out of scope for handling cardholder data.

In cases where the payment gateway does not provide a hosted payment page, an API-driven payment strategy must be considered. This approach requires tighter integration between Salesforce and the gateway, with careful design to ensure that sensitive data is securely transmitted and tokenized without being stored within Salesforce systems.

If no payment gateway is currently in place, organizations can adopt an AppExchange-based payment solution that integrates with widely used payment processors such as Stripe. These solutions typically provide prebuilt integrations, tokenization capabilities, and compliance support, enabling faster implementation while still aligning with Payment Card Industry Data Security Standard requirements.

AppExchange Payment Strategy

In a Salesforce-centric payment architecture, one approach is to manage payments and invoices directly within Salesforce using an AppExchange payment solution. In this model, Salesforce acts as the system of record for transaction data, including payments, orders, and invoices. When a user initiates a payment (e.g., via Experience Cloud or a custom Salesforce app), the request is securely routed to the payment gateway, which handles tokenization and forwards the transaction to the payment processor for authorization and settlement. Salesforce stores only tokenized references and transaction metadata, ensuring that sensitive payment data does not reside within the platform while still maintaining full visibility into the payment lifecycle.

An alternative approach is to treat an external system as the system of record for payments and invoices, with Salesforce playing a supporting or orchestration role. In this pattern, Salesforce still facilitates the payment initiation and integrates with the payment gateway for secure processing, but the authoritative payment and invoice data is maintained in a downstream payment master system. Integration layers such as ESB or ETL tools are used to synchronize payment data between Salesforce and the external system, ensuring consistency while offloading core financial data management.

The choice between these approaches depends on factors such as system ownership, scalability requirements, and enterprise architecture standards. Managing payments within Salesforce provides tighter integration and real-time visibility for business users, whereas leveraging an external payment master system can offer greater control, extensibility, and alignment with enterprise financial systems. In both cases, the payment gateway and processor continue to play a critical role in ensuring secure, PCI-compliant handling of payment data.

Hosted Payment Gateway

This architecture represents a hosted payment gateway integration pattern within a Salesforce-centric experience, commonly used to minimize PCI scope and enhance security. In this model, an external user initiates a payment from a Salesforce application (such as an Experience Cloud site or custom UI). Instead of capturing payment details directly, Salesforce requests a secure, hosted payment URL from the payment gateway—typically via an integration layer such as an ESB.

The user is then redirected to the payment gateway’s hosted page, where all sensitive payment data is captured and processed. This ensures that cardholder data never passes through or is stored within Salesforce, aligning with best practices under the Payment Card Industry Data Security Standard. The payment gateway securely handles data storage, encryption, and communication with the payment provider for authorization and settlement.

Once the transaction is completed, the payment gateway sends a callback (often via webhook or API) containing the transaction status back through the integration layer. The ESB then updates the relevant Salesforce records with the payment outcome, ensuring that Salesforce maintains visibility into transaction status without ever handling sensitive payment information.

This pattern is particularly effective for reducing compliance scope, as Salesforce only manages non-sensitive transaction metadata while delegating all payment data handling to the PCI-compliant gateway. It also simplifies security considerations while maintaining a seamless user experience through secure redirection and real-time status updates.

API Payment Strategy

In an API-led payment architecture, sensitive payment information such as credit card numbers (PAN), bank account details, and other transient financial data is securely captured at the edge of the system and processed through a controlled integration layer.

Once captured, this sensitive payload is programmatically encrypted using a shared X.509 certificate. In platforms such as Salesforce, this is typically achieved using the Crypto class to perform asymmetric or symmetric encryption before transmission. The goal is to ensure that payment data remains protected in transit and is never exposed in plain text across integration boundaries.

The encrypted request is then submitted to a Payment Gateway through a dedicated payment processing API. The gateway acts as the secure intermediary responsible for validating, tokenizing, and forwarding the transaction to the downstream payment processor or acquiring bank. Upon successful processing, the payment gateway returns a transaction response, which is then used to update core financial systems such as the Billing System or ERP (Enterprise Resource Planning system). These updates typically include payment status, invoice reconciliation, and settlement confirmation.

To expose this financial and operational data back to business users, the architecture leverages an OData 4.0 adapter. This layer performs protocol transformation and data mediation, enabling standardized access to invoice, payment, and transaction datasets. By converting backend ERP or billing system responses into OData-compliant endpoints, Salesforce can consume and present this information seamlessly within its user interface for operational reporting, customer service, and finance teams. Overall, this architecture enables a secure, extensible, and standardized way to manage payment lifecycle events while ensuring that end users in Salesforce have real-time visibility into invoices and payment statuses without directly interacting with backend financial systems.

Conclusion

Payment scenarios in Salesforce require careful architectural decisions to balance security, compliance, and usability. While Salesforce is PCI DSS Level 1 compliant, achieving end-to-end compliance remains a shared responsibility, requiring proper design, configuration, and governance. The most effective approach is to minimize exposure to sensitive data through strategies like tokenization and by leveraging payment gateways to handle secure data capture and processing.

Architectural patterns—such as hosted payment pages, API-led integrations, or AppExchange solutions—should be selected based on the organization’s system landscape, always prioritizing reduced PCI scope and secure data handling. Ultimately, a well-designed payment architecture ensures that sensitive data is never unnecessarily stored or exposed, while still enabling seamless payment experiences and operational visibility across systems.