Data flow diagram depicting the order capture data flow

This topic depicts the data flow diagram of order capture flow.

This section describes the flow of cardholder data or Payment Application Number (PAN) for an order capture and a payment authorization transaction.

The following Data Flow diagram shows the order capture function.

Data Flow Diagram depicting the order capture data flow

In this illustration, the flow of PAN and order information takes two distinct paths.

First Path:

  1. Sensitive PAN information from the user is sent to the capture PAN.
  2. This information is then sent to the proxy PAN to vault process.
  3. The information goes to the credit card vault for storage.

Second Path:

  1. The captured order information flows from the user to the capture order process.
  2. During the capture order process, the PAN token from the first path and the order information are sent to the process order process.
  3. The order information and PAN token are stored in the order store.

The key point here is that second path does not touch or process sensitive PAN information.

The following illustration shows how the processes in the previous Order Capture Data Flow illustration are partitioned into the Distributed Order Management (DOM), Sterling Call Center, Sterling Call Center (COM) and Sterling Store Engagement (Legacy) (SOM), and Sterling Field Sales applications (FS apps).

Illustration of the processes in the previous order capture data flow

In terms of software partitioning, the PAN is captured in the browser separately from the order information, as follows:

  1. From the browser, PAN information is sent to the SSDCS as a tokenization request.
  2. This tokenization request, in turn, sends the PAN to the credit card vault.
  3. The credit card vault tokenizes and stores the PAN and returns a token.

The second path from the browser to the actual DOM, COM, or SF applications contains only the order information and PAN token, not the actual, cleartext (unencrypted) PAN. As a result, the order store contains only tokens.

From a PCI PA-DSS and PCI DSS perspective, the flows in the previous two illustrations are important, showing that architecturally, the DOM, COM, and FS applications do not touch PAN. This means that these applications may be kept outside of the PCI DSS auditing scope.

Payment processing transaction example

The following diagram illustrates a Payment Processing Transaction.

An example payment processing transaction flow from order to payment processed.

In this Payment Processing Transaction illustration, the order payment process prepares an order that requires payment authorization for transmission to a payment processor as follows:

  1. Because the order store has only tokens, the order payment process sends the payment request with the token to the proxy payment process.
  2. The proxy payment process detokenizes the token back to the cleartext (unencrypted) PAN, and replaces the token in the payment request.
  3. The proxy payment process then forwards the payment request to a payment processor.

In the following illustration, the data flow diagram shown in the previous illustration is partitioned into software components.

The data flow diagram shown in the previous illustration is partitioned into software components

In this illustration, the task of detokenization is delegated to a component called the Payment Abstraction Layer (PAL). This is a customer-provided component. This partitioning approach serves two critical purposes:

  • The places where tokens can be converted to PAN are limited and controlled.
  • This approach ensures that the IBM® applications do not have access to PAN, and therefore, cannot process PAN. As a result, the IBM applications can be kept outside of the PCI DSS auditing scope.