Things to know before upgrading your skillset to EMV Certification Analyst/Specialist

Components of payment processing

Payment processing involves multiple components that work together to enable secure, efficient transactions between the customer and the business.

These components include:

1. The customer: the individual or entity that initiates the payment for goods or services.

2. The merchant: the business or service provider that accepts the payment from the customer.

3. The payment method: the method that the customer uses to make the payment, such as credit cards, debit cards, electronic wallets or cryptocurrencies.

4. The point-of-sale (POS) system: the physical or digital platform where the transaction takes place, such as a retail terminal, e-commerce website or mobile app.

5. The payment gateway: a service that securely captures and transmits payment information from the POS system to the payment processor or acquiring bank, ensuring the encryption and security of sensitive data during the transaction process.

6. The payment processor: a third-party company that handles the technical aspects of the transaction, including validating payment information, obtaining authorisation and managing communication between the acquiring and issuing banks.

7. The acquiring bank, or acquirer: the financial institution that holds the merchant's account, receives the payment on its behalf, processes the transaction and settles the funds in the merchant's account.

8. The card network: organisations (e.g. Visa, Mastercard and American Express) that establish the rules, standards and infrastructure for processing transactions, using their branded payment instruments.

9. The issuing bank, or issuer: the financial institution that has issued the payment instrument to the customer and is responsible for authorising or declining the transaction, based on the customer's account status, available funds and other factors.

10. Payment security: technologies and standards, such as the Payment Card Industry Data Security Standard (PCI DSS), tokenisation or encryption, that ensure the safety and integrity of payment information and protect against fraud and data breaches.

11. Settlement and reconciliation: the process of transferring funds between the issuing bank and the acquiring bank, followed by updating the merchant's account and generating transaction records for both the customer and the merchant.

    
    

Each component plays an important role in the process, ensuring that transactions are completed securely, efficiently and in compliance with applicable regulations and industry standards.

How does payment processing work?

The process involves several steps and multiple parties. Here's an explanation of how payment processing works:

1. Transaction initiation: The customer initiates the payment by providing their payment information (e.g. a credit card, debit card or another payment method) at the point of sale in a physical shop, or through an online platform, such as an e-commerce website or mobile app.

2. Payment gateway: Once the customer has submitted their payment information, it's transmitted securely to the payment gateway, which acts as a bridge between the customer, the business and the payment processor. The payment gateway is responsible for encrypting the transaction data and ensuring that the data is transmitted securely to the payment processor or the acquiring bank.

3. Transaction authorization: The payment processor receives the transaction data from the payment gateway and validates the information. It then forwards the transaction details to the acquiring bank, which sends the information to the card network for validation and authorisation.

4. Issuing-bank verification: The card network forwards the transaction details to the issuing bank. The issuing bank verifies the customer's account status and checks the available balance or credit limit, before assessing any potential risks. Based on these factors, the issuing bank either approves or declines the transaction.

5. Authorisation response: The issuing bank sends the authorisation response (whether it is an approval or a decline) back through the card network to the acquiring bank, which then forwards the response to the payment processor. The payment processor then sends the response to the payment gateway, which communicates the result to the business's POS system or online platform.

6. Transaction completion: If the transaction is approved, the business completes the sale by providing the customer with the goods or services. If the transaction is declined, the business may request an alternative payment method from the customer.

7. Transaction settlement: At the end of each day, the business sends a batch of approved transactions to the payment processor or the acquiring bank for settlement. The acquiring bank requests the funds from the issuing bank through the card network. The issuing bank transfers the funds to the acquiring bank, which then deposits the money into the business's account, usually within a few working days.

8. Reconciliation and reporting: The business reconciles the settled transactions with its sales records and any transaction fees charged by the payment processor, acquiring bank or other parties involved. Both the business and the customer receive transaction records, such as invoices, receipts or account statements.

The three levels of EMV certification ensure that payment devices and software adhere to EMV standards, from the hardware level (Level 1) to the software components (Level 2) and the integration with payment applications and networks (Level 3).

• Level 1 certification is the responsibility of the device hardware supplier

• Level 2 certification is the responsibility of the device software supplier

• Level 3 testing ensures the conformity of merchant terminals to payment systems policies and procedures.

GSTP is a developer sandbox and the tool to complete certifications

• Create custom test scripts that includes EMV test scripts and allows the dev to perform unattended testing and view the results with details of any coding errors.

B2 CIT

• Used to test Gateway and middleware solution

Collis Merchant Test Suite

• Provides true card simulation by emulating all the functions of an actual EMV chip

Collis Card Spy

• Gives you the ability to trace, capture and analyse a transaction between a device (POS) and an actual EMV card

ICC Solutions:

• Another EMV test tool that majorly uses Merchant test cards to test terminal configuration and ensure that is accepts and returns the correct responses.

Fime/Savvi:

• A single tool for faster, simpler brand terminal certifications

• Acquirers and merchants who deploy new EMV terminals must test and certify in line with multiple brand requirements

• Savvi Test Platform significantly reduces the time needed to successfully complete L3 terminal integration testing

The overall testing process is divided into multiple steps:

Unattended Testing

Unattended testing (Test Mode in the GSTP) is where the software developer can perform code testing, unit testing or error debugging.

Attended Testing

Attended testing (Certification Mode in the GSTP) is where the software developer runs scheduled Global Payments and Brand certification testing with their Certification Coordinator.

Production Readiness Testing

Production readiness testing will be administered as a screening prior to moving into production.

Production Monitoring

The Certification Coordinator must monitor each software developer’s initial installations for 3 months to ensure there are no production issues.

Completion

The Certification Coordinator closes the project in the GSTP after the 3 month monitoring period.

Annual Review

Product Integration collects proof of compliance on an annual basis.

An EMV (Europay, MasterCard, and Visa) transaction process involves several steps, starting from the moment a card is inserted into the terminal to the completion of the transaction. Here is a detailed description of each step:

1. Card Insertion

• Cardholder Action: The cardholder inserts the EMV chip card into the payment terminal's chip reader.

• Terminal Action: The terminal detects the presence of the card and establishes a connection with the chip.

  
  

2. Application Selection

• Terminal Action: The terminal reads the Application Identifiers (AIDs) from the card.

• Cardholder Action: If multiple applications are available (e.g., credit and debit), the terminal might prompt the cardholder to choose one.

3. Initiate Application Processing

• Terminal Action: The terminal sends a command to the card to initiate application processing. The card responds with its application information and public key certificate.

  
  

4. Read Application Data

• Terminal Action: The terminal reads essential data from the card, such as the Primary Account Number (PAN), expiration date, and cardholder name. This step involves reading the necessary data objects from the card.

  
  

(Data objects are Basic Encoding Rules-Tag Length Value (BER-TLV) coded, as defined in – ISO/IEC 8825 - ISO/IEC 8825-1:2015 specifies a set of basic encoding rules that may be used to derive the specification of a transfer syntax for values of types defined using the specified notation. The Basic Encoding Rules (BER) are a set of Abstract Syntax Notation One encoding rules that define a specific way in which information may be encoded in a binary form.

A "tag-length-value" (TLV) construction is a byte array that has  – 

A tag indicating what the data is

The Tag field consists of one or more consecutive bytes. It indicates a class, a type, and a number. EMV tags are coded on one or two bytes.

A length specifying its length (in bytes/octets)

• The Length field consists of one or more consecutive bytes that indicate the length of the following value field.

• If bit 8 of the most significant byte of the length field is set to 0, the length field consists of only one byte. Bits 7 to 1 code the number of bytes of the value field, for lengths from 1 to 127.

• If bit 8 of the most significant byte of the length field is set to 1, the subsequent bits 7 to 1 code the number of subsequent bytes in the length field.

• The subsequent bytes code an integer representing the number of bytes in the value field. Two bytes are necessary to express lengths from 128 to 255.

The value itself.

The Value field indicates the value of the data object. If L = 00, the value field is not present.

5. Offline Data Authentication (if applicable)

• Terminal Action: The terminal performs Offline Data Authentication (ODA) to verify the authenticity of the card.

• There are three methods for this:

  
  

  • Static Data Authentication (SDA): The terminal checks the static signature of the card data.

  • Dynamic Data Authentication (DDA): The terminal verifies a dynamic signature generated by the card.

  • Combined Data Authentication (CDA): Combines both SDA and DDA for enhanced security.

6. Processing Restrictions

• Terminal Action: The terminal checks for any restrictions on the card usage (e.g., expired card, country restrictions).

7. Cardholder Verification

• Terminal Action: The terminal determines the Cardholder Verification Method (CVM) to use (e.g., PIN, signature, or no CVM required).

• Cardholder Action: The cardholder may need to enter a PIN or provide a signature.