How to use AWS Payment Cryptography Service to simplify payment flows

Securing card payment transactions while maintaining operational efficiency is a critical challenge for businesses of all sizes. The global network brand cards such as Visa, UnionPay, Mastercard, American Express, JCB and Discover/Diners Club generated $36.741 trillion in purchase volume worldwide in 2024. As such, card payments trend is only expected to grow further and the need to keep payments secure grows with it. AWS Payment Cryptography represents a significant leap forward in simplifying payment security infrastructure.

This fully managed service eliminates the complexity of handling payment credentials and cryptographic operations, addressing key pain points for financial institutions and removing the overhead of managing cryptographic infrastructure. Whether you’re processing credit card transactions, managing PIN operations, or securing payment tokens, AWS Payment Cryptography provides a simplified API based approach to payment security that meets the stringent requirements of the payment card industry while reducing operational overhead and costs.

In our previous post, we delved into how companies can synchronize their working keys from various HSM types to AWS Payment Cryptography. Now, we’ll dive into various issuer and acquirer-based use cases. In this post, we have only provided a subset of uses cases supported by AWS Payment Cryptography. Refer to the user guide for a comprehensive list. For all of the flows and use cases discussed here, we provide sample code available in a GitHub samples repository.

By the end of this blog post, you’ll have practical, implementation-ready knowledge to modernize your payment infrastructure using AWS Payment Cryptography.

Let’s dive into the use cases.

Note: All the flows discussed below require keys to be generated or imported in AWS Payment Cryptography. Except for ECDH related PIN set, reveal and reset flows, the sample flows use pre-created keys on the client side (simulated terminal). We imported these pre-created plain text keys into AWS Payment Cryptography as BDK, PEK, ARQC, etc. working keys to support the different cryptographic operations.

Plain text keys can be used in samples or non-production environments only. They must not be used in production environments and should instead be generated.

As a first step, check out the sample code from Github samples repository to test flows from sections below.

Acquirer Flows

1. Point-to-Point Encryption (P2PE). The AWS Payment Cryptography service is PCI P2PE compliant and is registered as a PCI P2PE decryption component.

Payment data (especially pan data) gets encrypted by a payment terminal and needs to be decrypted by the backend. Encrypt Data and Decrypt Data functions of AWS Payment Cryptography support this via a variety of cipher methods such as TDES 2KEY, TDES 3KEY, AES-128, AES-256 and also DUKPT derivation techniques.

The following sample flow shows the P2PE flow from terminal to backend using AWS Payment Cryptography.

Figure 1 – P2PE (DUKPT) FLOW

Testing the flow:

1. Ensure the server is running
   cd samples-for-payment-cryptography-service/java_sdk_example ./run_example.sh aws.sample.paymentcryptography.Application
2. Execute the command below to simulate a payment terminal sending authorization requests to the server. - ./run_example.sh aws.sample.paymentcryptography.terminal.PaymentTerminal

Refer to Github samples for more details on running this flow.

2. PIN Translation. PIN translation functions are used to translate encrypted PIN data from one set of keys to another without the encrypted data ever leaving the HSM. In a typical scenario, a user enters a PIN on a payment terminal. The PIN gets encrypted with the payment processor’s key within the terminal and is sent to the processor. The payment processor then translates the PIN from its key to the acquirer’s working key (AWK) before passing it to the acquirer. This translation flow then continues through other entities, payment networks, and finally the issuer of the card which validates the PIN. The PIN translation across the entities can be between different ISO formats. For example, the payment terminal can encrypt the PIN in ISO4 format, and the processor can translate it from ISO4 to ISO0 format. AWS Payment Cryptography supports PIN translation functions for ISO0, ISO1 and ISO4 PINblock formats. The diagram below illustrates this flow in the sample application.

Figure 2 – Pin Translation Flow

Testing the flow
In order to test the PIN translation flow, you will first need to set the PIN by executing the following commands.
This is a simulation of a user setting a PIN in an ATM. Here, the clear text PIN gets encrypted and sent to the backend. Upon receiving the PIN, the backend (typically the issuer) then returns a PIN verification value, which gets stored for future PIN verification.

cd samples-for-payment-cryptography-service/java_sdk_example
./run_example.sh aws.sample.paymentcryptography.terminal.ATM

Once the user sets the PIN, you can run the following set of commands which trigger the flow to verify the PIN. In this flow, the PIN in the PINTerminal (typically payment terminal in merchant store) is encrypted in ISO0 standard.

cd samples-for-payment-cryptography-service/java_sdk_example
./run_example.sh aws.sample.paymentcryptography.terminal.PINTerminal_ISO_0_Format

Refer to Github samples for details on running this flow.

3. MAC Generation. Message Authentication Codes (MAC) are typically used to authenticate the integrity of a message (whether it’s been modified). Cryptographic hashes such as Hash-Based Message Authentication Code (HMAC), Cipher-based Message Authentication Code (CBC-MAC and CMAC) provide an additional assurance to the sender of the MAC by utilizing cryptography. If even one character of the message changes, or if the secret key changes, the resulting tag is entirely different. By requiring a secret key, cryptographic MACs also provide authenticity; it is impossible to generate an identical mac without the secret key. Cryptographic MACs are sometimes called symmetric signatures, because they work like digital signatures, but use a single key for both signing and verification. AWS Payment Cryptography supports several types of MACs as outlined in the user guide.
We illustrated the HMAC generation in the P2PE flow above, where the response from the backend contains the generated HMAC.

Refer to the code sample on generating HMAC in AWS Payment Cryptography.

Issuer Flows

1. PIN Verification Value generation. PCI-PIN control objective 1, requirement 4 prohibits long-term storage of PINs, so issuers generate and store a PIN Verification Value (PVV) for every PIN to authenticate the transactions while avoiding storing the PIN itself. When an Issuer wants to generate a new PIN for a cardholder, they can decide to generate a random PIN and send it to them or let them choose their own PIN and generate and store the related PVV for that PIN. AWS Payment Cryptography supports both cases, and you can see the user-guide in the documentation or follow the RESET PIN or SET PIN use-cases on code samples.

In this example we have an implementation between a mobile application and a backend application that interacts with AWS Payment Cryptography using Elliptic Curve Diffi Hellman (ECDH) algorithm to protect the PIN in transit.

cd samples-for-payment-cryptography-service/python_sdk_example/ecdh_flows

pip3 install -r requirements.txt

python3 payment_crypto/main.py

Figure 3 – Pin Reset Transaction Flow

Figure 4 – Pin Reset Flow

2. PIN Verification. For an incoming PINblock in a payment transaction, issuers need to verify it matches the known PIN value of that cardholder. For this, the issuer applications can use the verify PIN function of AWS Payment Cryptography with the stored PIN Verification Value (PVV) for that card data.

The following diagram illustrates the PIN verification flow in the sample application.

Figure 5 – Pin Verification Flow

Testing the flow

To test the PIN verification flow, first you will need to set the PIN by executing the commands below.
This is a simulation of a user setting a PIN in an ATM. Here, the clear text PIN gets encrypted and sent to the backend. Upon receiving the PIN, the backend (typically the issuer) returns a PIN verification value which gets stored for future PIN verification.

cd samples-for-payment-cryptography-service/java_sdk_example
./run_example.sh aws.sample.paymentcryptography.terminal.ATM

Once the user sets the PIN, you can run the commands below to trigger the flow to verify the PIN. In this flow, the PIN in the PINTerminal (typically payment terminal in merchant store) is encrypted in ISO0 standard. The backend uses the encrypted PIN data, PIN verification value, ISO format of PIN encryption and related keys to verify the PIN.

cd samples-for-payment-cryptography-service/java_sdk_example
./run_example.sh aws.sample.paymentcryptography.terminal.PINTerminal_ISO_0_Format

Refer to PIN verification code at VeifyPINData method in IssuerService for details.

3. Auth Request Cryptogram Validation. Authorization Request Cryptogram (ARQC) is a cryptogram generated by an EMV (chip) card and used to validate the transaction details, as well as the use of an authorized card. It incorporates data from the card, terminal, and the transaction itself. As part of the payment transaction, the payment terminal sends ICC data per EMV specifications to the backend which contains the ARQC along with other payment related data. After receiving the payment request, the issuer backend constructs the transaction data from the ICC field based on the EMV tags to generate the ARQC cryptogram which is then compared against the incoming ARQC. If the ARQC matches, the transaction is valid, otherwise it returns an error.

The following diagram illustrates the ARQC validation flow in the sample application –

Figure 6 – Pin Verification Flow with ARQC

In the sample code, the ARQC validation happens as part of the PIN verification flow as shown in Figure 6. The code uses pre-created transaction data which is used to create the ARQC on the terminal. This cryptogram, along with the transaction data, is sent to the backend which then validates the ARQC using transaction data and the ARQC key. Refer to verifyARQCCryptogram method in the IssuerService for details.

4. Card Verification Value Validation. While processing card-not-present transactions, issuers usually leverage the card printed CVV2/CSC code to verify the authenticity of the transaction. This value is a cryptographic function based on the card’s Primary Account Number (PAN), a cryptographic key, the card’s expiration date, and the Service Code used for the operation. The algorithm may vary between brands and code versions and you can leverage the user-guide and the technical guide to find the algorithm that fits your needs. We have the CVV2/CSC sample in github repository that simulates the issuance of CVV2 or CSC, and then plays the role of authorizer, validating the authorization code.

cd samples-for-payment-cryptography-service/python_sdk_example/ecdh_flows

pip3 install -r requirements.txt

python3 payment_crypto/main.py

5. Transaction-time Card Verification Value generation and validation. In some countries, regulators and issuers are switching away from the printed Card Verification Value, adding strength by using a dynamically generated value when the user wants to purchase online. Technical implementations vary from issuer to issuer, but they usually rely on a Payment HSM to generate and validate the dynamically generated value. AWS Payment Cryptography supports such scenarios by smartly leveraging the generate and validate card data functions.

6. Revealing cleartext PIN from PINblock. In some very specific cases, issuers may need to decipher a given PINblock to obtain the cleartext PIN, this can be achieved by generating a local PIN Encryption Key (PEK) and asking a Payment HSM to generate a PINblock translation from the given PINblock to that locally generated PEK, and then use that local PEK to decrypt the PIN. Normally, Elliptic-Curve Diffie-Hellman (ECDH) is leveraged to increase the cryptographic strength of this workflow. You can find the code sample in github repository under PIN REVEAL tag.

Figure 7 – Reveal Pin Transaction Flow

cd samples-for-payment-cryptography-service/python_sdk_example/ecdh_flows

python3 -m venv .venv && source .venv/bin/activate && pip3 install -r requirements.txt

python3 payment_crypto/main.py

Conclusion

As we’ve shown through the use cases above, AWS Payment Cryptography Service represents a paradigm shift in how financial institutions can approach payment cryptographic operations. Organizations no longer have to provision and maintain payment HSM hardware and instead focus on business innovation. Further, the operations in AWS Payment Cryptography are API based instead of socket based HSM commands which allow for larger talent pool within organizations to contribute to payment cryptography applications subsequently speeding time to market. Refer to user guide to get started with AWS Payment Cryptography and modernize your payment applications.