Card Present Processing via Open Platform


CyberSource enables third party Payment Technology Providers (PTP) to provide Card-Present acceptance solutions to clients through Open Platform Enablement model. A Card Present transaction occurs when the cardholder is present at the merchant's physical place of business. The card data is either read via mag-stripe, EMV (contact, contactless), or hand-keyed (if the chip or mag-stripe data cannot be read/obtained).

                                                                                                                                                                              

 

Acquirer Processor Model

 

PTPs can use Card present processing via Open Platform to process card present transaction. CyberSource card present platform is host certified with processors. For Processors and card present service coverage kindly refer section processor and services  
 

Supported Processors

Processor

EMV ( Europay, Mastercard , Visa)

Contact and Contactless

Magnetic Stripe

American Express Direct—supports card-present processing only for merchants in the U.S. who are transacting in U.S. dollars.

Yes

Yes

Chase Paymentech Solutions

Yes

Yes

Credit Mutuel-CIC

Yes

Yes

FDC Nashville Global

Yes

Yes

FDMS Nashville

No

Yes

GPN

Yes

Yes

JCN Gateway—Visa is the only card type supported on JCN Gateway for card-present transactions

Yes

Yes

OmniPay Direct—First Data Merchant Solutions (Europe) only

Yes

Yes

RBS WorldPay Atlanta

No

Yes

SIX

Yes

Yes

TSYS Acquiring Solutions

No

Yes

Worldpay VAP—Worldpay VAP was previously called Litle. Litle was purchased by Vantiv, which was then purchased by Worldpay VAP. If you have any questions, contact your account manager at Worldpay VAP.

No

Yes

* EMV - EMV is a global standard for exchanging information between chip cards and POS terminals. A chip card is a credit or debit card with an embedded microchip. A chip card also has a magnetic stripe on the back of the card, which can be used for a back-up transaction when the card’s chip cannot be read. The EMV standards define the protocols for all levels of transmission between chip cards and chip card processing devices: physical, electrical, data, and application.

Once you have the right processor coverage:
        - Contact your acquirer to find out whether you are allowed to process card-present transactions.
        - Find out from your acquirer and CyberSource Customer Support whether you must have a separate
            CyberSource merchant ID for your card-present transactions.
        - Contact CyberSource Customer Support to have your account configured to process card-present transactions.

Scope for Services 

In summary, the integration from partner to CyberSource should support the following services.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Transaction Types 

Authorization 

Ability to process a final authorization only without a bill/capture request to authorize a card for an amount. The merchant can also request to have the card details tokenized as a CyberSource profile, which can be used for follow-on and card-on-file transactions. MerchantTransactionIdentifer is supported in Authorization

Sale (Authorization + Capture) 

A sale is a bundled authorization and capture. You can use a sale instead of a separate

authorization and capture if there is no delay between taking a customer’s order and

shipping the goods. A sale is typically used for electronic goods and for services that you

can turn on immediately or a card present transaction. The merchant can also request to have the card details tokenized as a CyberSource profile, which can be used for follow-on and card-on-file transactions. merchantTransactionIdentifer is supported in Sale

Credit (Standalone) 

When the request for a credit is successful, the funds are taken from the merchant's

account and transferred back to the cardholder. It usually takes two to four days for the acquiring bank to transfer funds from the merchant's bank account.

 

merchantTransactionIdentifer is supported in Credit

Auth Reversal 

Ability to reverse an original authorization from an authorization only or sale request due to the terminal or the partner not receiving a response back for a transaction due to a potential timeout. CyberSource provides merchantTransactionIdentifer field that a partner can specify in the original authorization request. Then if a timeout occurs, the partner can utilize the merchantTransactionIdentifer field (instead of the authRequestID field) to process an auth reversal request, as well as a void request.

Void 

Ability to process a void and authorization reversal through the card terminal if required by the merchant. A void cancels a capture or credit request that you submitted to the system. A transaction

can be voided only if the system has not already submitted the capture or credit request.

merchantTransactionIdentifer is supported in Void

Verbal Auth/Forced Capture 

Ability to obtain a manual authorization code by the merchant calling their processor and processing the sale request with the code. This will process a sale request offline that reflect directly on the merchant batch records. The offline verbal authorization doesn’t process through CyberSource. When you request an authorization through the system, the issuer might ask that you call

the acquirer to answer questions about the transaction. These transaction types are

sometimes known as Referrals.

merchantTransactionIdentifer is supported in verbal Auth

Follow-On Capture  

Ability to process a bill request through CyberSource as a follow-on from the original authorization only request. Follow-on captures can also be processed through the merchant’s server or POS register by sending the request directly to the CyberSource API using the original authorization request ID.

Debit Purchase 

Ability to move money from your customer’s account into your account as a single message request that does not require a subsequent capture.

Debit Credit 

Ability to move money from your account into your customer’s account that is not linked and processed as a single message request.

Debit Reversal 

Ability to reverse either a PIN debit purchase or credit that is linked to the original request ID as a follow-on transaction.

Timeout Reversal (EMV)

In this case, an EMV transaction has not completed successfully due to technical error or timeout. In the cases below, the authorization may or may not have been successful with the processor, but there is no way for the merchant to know. When this happens, the authorizations should be reversed so that funds are released back to the consumer immediately. As a best practice utilizing measured data, 50 seconds is the recommended time by CyberSource for partners to initiate a reversal if no response is received.

The following scenarios should be accounted for by the partner or CyberSource:

 Partner does not receive a response from CyberSource → Partner must query CyberSource to get transaction details, and process an auth reversal if CyberSource has a record of a successful authorization.

 The terminal sent a request but doesn’t acknowledge a response → Partner must query CyberSource to get transaction details, and process an auth reversal if CyberSource has a record of a successful authorization.

 CyberSource receives no response from the processor → CyberSource must process an auth reversal to the processor.

 CyberSource receives a timeout response from the processor → CyberSource must process an auth reversal to the processor.

 

Refund (EMV)

Merchants should be able to process a standalone refund through the card terminal and partner to CyberSource. This case gives the merchant the ability to process the refund request through the terminal, which would include the credit card PAN and EMV block. Note that is it not a follow-on refund request.

Cancellation (EMV)

After an EMV transaction has completed successfully, the consumer may ask for a refund following the sale in-store. Typically, this scenario is catered by a refund, however, the merchant can process this cancellation before the batch cut off by using a CyberSource void plus auth reversal, which requires the card to be provided by the consumer.

Partners initiate the process by first sending a void using the original CyberSource request ID and then initiate an auth reversal request that requires the EMV block to be sent from the terminal.

Timeout Reversal (MSR)

In this case, a MSR transaction has not completed successfully due to technical error or timeout. In the cases below, the authorization may or may not have been successful with the processor, but there is no way for the merchant to know. When this happens, the authorizations should be reversed so that funds are released back to the consumer immediately. As a best practice utilizing measured data, 50 seconds is the recommended time by CyberSource for partners to initiate a reversal if no response is received.

The following scenarios should be accounted for by the partner or CyberSource:

 Partner does not receive a response from CyberSource → Partner must query CyberSource to get transaction details, and process an auth reversal if CyberSource has a record of a successful authorization.

 The terminal sent a request but doesn’t acknowledge a response → Partner must query CyberSource to get transaction details, and process an auth reversal if CyberSource has a record of a successful authorization.

 CyberSource receives no response from the processor → CyberSource must process an auth reversal to the processor.

 CyberSource receives a timeout response from the processor → CyberSource must process an auth reversal to the processor.

 

Refund (MSR)

Merchants should be able to process a standalone refund through the card terminal and partner to CyberSource. This case gives the merchant the ability to process the refund request through the terminal, which would include the credit card PAN. Note that is it not a follow-on refund request.

Cancellation (MSR)

After a MSR transaction has completed successfully, the consumer may ask for a refund following the sale in-store. Typically, this scenario is catered by a refund, however, the merchant can process this cancellation before the batch cut off by using a CyberSource void plus auth reversal, which requires the card to be provided by the consumer.

Partners initiate the process by first sending a void using the original CyberSource request ID and then initiate an auth reversal request with the card data.

Offline transaction / Store & Forward

The partner should have the ability for transactions to be either queued or sent for processing after the consumer has departed when the terminal cannot go online.

Verbal Authorization

When attempting to process a transaction in-store and a processing issue occurs, an associate at the merchant location can call their processor to obtain an authorization code that can be used to process the MSR card-present transaction.

Endless Aisle

This is a case where a customer who is in-store, but is unable to find their item at the location. A merchant associate is able to identify the find the item in another store or distribution center and would like to take the payment in-person to then have the item shipped to the customer’s home.

From a processing perspective, this would require either authorization only (more likely) or sale to be completed from the card terminal while distribution of the item would occur as a separate process. Potentially, the ability to map to a different merchant MID would be required to be passed through.

In person Tokenization

All authorizations and sale requests from the partner to CyberSource must include a call to tokenize the card details. In the authorization response, CyberSource will include a profile token representing the card. This token can then be used for follow-on transactions, such as future authorizations, refunds or other Omni-channel purposes. The partner must pass the token onto the merchant.

 

An example of a common case is a health practitioner who will authorize and tokenize the card details for their customer in-person for the likely amount for a medical visit. The practitioner validates the billing specifics for customer with their insurance carrier. If there’s no change in the amount, then they will bill for the authorization amount. If there are changes in the policy/coverage, then the practitioner can reverse the original authorization and utilize the token generated from the in-person authorization to re-bill for the appropriate amount without having to re-engage the customer.

Optional features – Auth with payment network token

Authorizations with
Payment Network Tokens

You can request a credit card authorization with a payment network token instead of a primary account number (PAN). For information about adding this functionality to an order management system that already uses CyberSource credit card services, see Authorizations with Payment Network Tokens Using the REST API.

 

Balance Inquiry 

Ability to request balance information for an account.

Entry Modes 

Swipe 

 

Support for traditional magnetic stripe swipe on the card terminal. This is a straightforward magnetic swiped transaction through the card terminal by the customer who may not have a chip-enabled credit card. In this case, the partner passes the track data without the EMV block to CyberSource who then forwards to the acquirer.

 

Keyed 

 

Support for manual keyed entry of cards usually by a merchant associate that is  entered on the card terminal directly.

 

In the case of manual key entry, there are two primary use cases to be  accounted for in the solution set.

 A customer calls a merchant location where the associate takes card over the phone and enters the card via the card terminal where the payment is processed as MOTO (card-not-present) using key entry.

 A customer at a merchant location where the card cannot be chip read or MSR read. The customer hands card to associate who can then manually enter card via the card terminal and payment is processed as retail (card-present) using key entry. This assumes the merchant company/store policy allows key entry in-store.

 

Contact EMV (PIN & Signature) 

 

Support for EMV cards using signature cardholder verification, or No CVM which does not require a signature or PIN verification.

Quick Chip – As a Visa company, all EMV solution integrations with partners should support Quick Chip implementations for end-customers. The EMV tag 9F02 will have the final amount when known (as opposed to the predetermined amount). The experience should use a default arbitrary transaction value (dependent by processor) to support the following experience:

§ Insert Card

§ Read the Chip Data

§ Remove Card

§ Present Cardholder with Total

§ Get Issuer Authorization

§ Obtain Signature (is not a No CVM scenario)

 

Contactless 

 

Support for EMV cards using offline or online PIN cardholder verification, or No CVM which does not require a signature or PIN verification.

 

Quick Chip – As a Visa company, all EMV solution integrations with partners should support Quick Chip implementations for end-customers. The EMV tag 9F02 will have the final amount when known (as opposed to the predetermined amount). The experience should use a default arbitrary transaction value (dependent by processor) to support the following experience:

§ Insert Card

§ Read the Chip Data

§ Remove Card

§ Present Cardholder with Total

§ Get Issuer Authorization

§ Obtain PIN (is not a No CVM scenario)

 

American Express ExpressPay, Mastercard PayPass, Visa PayWave. are contactless transaction.

 

Card Types/AIDs 

Visa 

cardType - 001

MasterCard 

cardType - 002

American Express 

cardType - 003

Discover 

cardType - 004

Diners Club ( Processed thru Discover rails)

cardType - 005

Carte Blanche ( Processed thru Discover rails)

cardType - 006

JCB 

cardType - 007

Maestro (International) 

cardType - 042

China Union Pay 

cardType - 062

CVMs  

All CVM 

The Cardholder Verification Method, or CVM, is used to evaluate whether the person presenting a payment instrument, such as a payment card, is the legitimate cardholder.

Offline PIN 

This is a common transaction use case for global consumers and US Debit as cards are issued with PIN preferring CVMs. In this case, the consumers dips their card into the terminal and then provides their PIN to complete the transaction.Pin is offline verified by the terminal

Online PIN 

This is a common transaction use case for global consumers and US Debit as cards are issued with PIN preferring CVMs. In this case, the consumers dips their card into the terminal and then provides their PIN to complete the transaction. Pin is online verified by the acquirer

Signature 

This is a common transaction use case for North American consumers as cards are issued with signature preferring CVMs. In this case, the consumers dips their card into the terminal and then provides their signature to complete the transaction.

No CVM 

In this case, the consumer dips their card into the terminal and the transaction does not require a cardholder validation method after negotiation. This occurs for low dollar amount transactions that carry lower risk. In the US, the typical limits are  $25 for all MCCs (merchant category codes), and  $50 for super market & discount store MCCs.

Fallback to Swiped

If the chip is damaged or the card terminal’s chip reader is faulty, the merchant may fallback to a swiped transaction, while still gaining the liability shift and interchange benefits of an EMV transaction (dependent on acquirer). In this case, the partner passes CyberSource the track data and two additional fields of data (emvRequest_fallbackemvRequest_fallbackCondition), which indicates that the transaction is a fallback scenario.

Fall forward to EMV

In this scenario, the consumer has attempted a magstripe swipe transaction using an EMV enabled card. The response requires that a standard EMV transaction to be performed. CyberSource will respond to the partner with an issuer response code that requires the partner to challenge the consumer for a full EMV transaction. The new transaction should come to CyberSource as a distinct new payment request.

Industry/Commerce Indicators 

Retail 

 

Acceptance for processing in retail locations from the card terminal/solution.

 

MOTO

 

Acceptance for processing mail order or telephone order from the card terminal/solution.

 

 

AID Support:

Application Name 

AID

AID TYPE

MESSAGE TYPE

CYBS AUTH SERVICES

Amex

A00000002501

Global Credit

Dual

auth, bill, credit

Discover Common AID

A0000001524010

Common Debit

Dual

auth, bill, credit

Discover D-PAS

A0000001523010

Global Credit

Dual

auth, bill, credit

JCB

A0000000651010

Global Credit

Dual

auth, bill, credit

MasterCard

A0000000041010

Global Credit

Dual

auth, bill, credit

MasterCard Maestro

A0000000043060

Global Debit

Single

pinDebitPurchase, pinDebitCredit

MasterCard US Maestro

A0000000042203

Common Debit

Dual

auth, bill, credit

Visa

A0000000031010

Global Credit

Dual

auth, bill, credit

Visa Electron

A0000000032010

Global Credit

Dual

auth, bill, credit

Visa Interlink

A0000000033010

Global Debit

Single

pinDebitPurchase, pinDebitCredit

Visa U.S. Common Debit

A0000000980840

Common Debit

Dual

auth, bill, credit

China Union Pay (Pulse)

A000000333010101

Global Debit

Single

auth, bill, credit

China Union Pay (Credit)

A000000333010102

Global Credit

Single

auth, bill, credit

China Union Pay (Quasi)

A000000333010103

Global Credit

Single

auth, bill, credit

China Union Pay (Common)

A000000333010108

Common Debit

Dual

pinDebitPurchase, pinDebitCredit

 

EMV Sensitive Fields & Receipt Fields 

EMV Sensitive Fields

According to brand rules and enforce by CyberSource, partners should not the pass the following EMV tags with transaction requests. These fields contain sensitive cardholder data in EMV Field 55 and are not required by CyberSource processing connections.

·        56: Track 1 Equivalent Data

·        57: Track 2 Equivalent Data

·        5A: Application PAN

·        5F20: Cardholder Name

·        5F24: Application Expiration Date

·        99: Transaction PIN

·        9F0B: Cardholder Name (Extended)

·        9F1F: Track 1 Discretionary Data

·        9F20: Track 2 Discretionary Data

For captures, this field is required for contact EMV transactions. Otherwise, it is optional. For credits, this field is required for contact EMV stand-alone credits and contactless EMV stand-alone credits. Otherwise, it is optional. Important For contact EMV captures, contact EMV stand-alone credits, and contactless EMV stand-alone credits, you must include the following tags in this field.

For all other types of EMV transactions, the following tags are optional.

·        95: Terminal verification results

·        9F10: Issuer application data

·      9F26: Application cryptogram

EMV receipt fields

Online Approved/Online Approved, Fallback FIELD

Field Name

Description

Required By

EMV tags

Application Name

The chip card application name used to process the EMV transaction.

Association

9F12

Application PAN

Must be printed on the receipt where the PAN must be truncated to remove any trailing characters and the PAN must be masked.

Association

5A

Card Entry Mode

Indicator how the card information was obtained. Chip Read – Card read from EMV chip. Contactless – Card read by contactless reader. FSwipe – Fallback swipe (insert attempted but failed). Swiped – Card swiped (not fallback).

Processor

-

Transaction Total

The receipt total line amount used to process the transaction.

Association

9F02

Transaction Currency

The receipt total line currency used to process the transaction.

Association

5F2A

Cardholder Verification

The Cardholder Verification Method (CVM) used for the transaction that must be printed on both the merchant and customer receipts.

Processor

-

Authorization Mode

Identifies the mode used to authorize/decline the transaction. Must be identified by the label “Mode”. Issuer – The transaction was sent online and approved/declined by the issuer, or when merchant is standing-in/performing a deferred authorization. Card – The transaction was approved/declined by the card without going online, or was stand-in approved by the merchant after being unable to go online.

Processor

-

AID

Application Identifier

Association

4F

TVR

Terminal Verification Results

Association

95

IAD

Issuer Application Data

Association

9F10

TSI

Transaction Status Indicator

Association

9B

ARC

Authorization Response Code

Association

8A

Authorization Code

The authorization code for the transaction.

Processor

-

Transaction Type

Type of transaction used to process.

Processor

-

Merchant ID

Merchant Identifier

Optional

-

Terminal ID

Terminal Identifier

Optional

-

Signature Line

Cardholder signature line must be printed.

Association

-

 

Offline Declined

FIELD NAME

DESCRIPTION

REQUIRED BY

EMV TAG

Tag 50

Application Label

Processor

50

Tag 5F2A

Transaction Currency Code

Processor

5F2A

Tag 5F34

PAN Sequence Number

Processor

5F34

Tag 82

Application Interchange Profile

Processor

82

Tag 95

Terminal Verification Results

Processor

95

Tag 9A

Transaction Date

Processor

9A

Tag 9C

Transaction Time

Processor

9C

Tag 9F02

Amount Authorized

Processor

9F02

Tag 9F03

Other Amount

Processor

9F03

Tag 9F07

Application Usage Control

Processor

9F07

Tag 9F0D

Issuer Action Code – Default

Processor

9F0D

Tag 9F0E

Issuer Action Code – Denial

Processor

9F0E

Tag 9F0F

Issuer Action Code – Online

Processor

9F0F

Tag 9F12

Application Preferred Name

Processor

9F12

Tag 9F1A

Terminal Country Code

Processor

9F1A

Tag 9F26

Application Cryptogram

Processor

9F26

Tag 9F27

Cryptogram Information Data

Processor

9F27

Tag 9F34

CVM Results

Processor

9F34

Tag 9F36

Application Transaction Data

Processor

9F36

Tag 9F37

Unpredictable Number

Processor

9F37

TAC Default

Terminal Action Code – Default

Processor

-

TAC Denial

Terminal Action Code – Denial

Processor

-

TAC Online

Terminal Action Code – Online

Processor

-

 

Open Platform card present workflow process

PTP interested in integrating to Open platform card present workflow should follow the below steps

Step 1: Onboarding


Work with CyberSource representatives to get on boarded on CyberSource platform with the processor of your choice. You will receive access to EBC2 Business center to procure REST API keys. 

Step2: Integration with REST APIs

 

REST APIs

Step 1: Create  test merchant with Cybesource.

REST API Authentication

Step 2:  Create  your own API Keys and  understand how to generate API headers.

Developer Guide

CyberSource Payment Services Developer Guides

 Card Present POSTMAN Collection

POSTMAN Collection

Checkout our Card Present specific PostMan Collection

 

 

Step 3:  Terminal Key management option

PTP owned key management

PTP manages data key and pin key encryption and decryption services on their own.

Requirements :

Kindly refer to the REST API fields to construct

 

Bluefin

Bluefin provides PCI-validated point-to-point encryption (P2PE)

 

1. When a customer swipes/ Dips a card through the Bluefin device, the device encrypts the card details at the hardware level and in accordance with PCI P2PE standards.

2. The device sends the encrypted payload to your order management system.

 3. Your order management system sends the encrypted payload to CyberSource in an authorization request or stand-alone credit request.

 4. CyberSource sends the encrypted payload to Bluefin to be decrypted and parsed. Bluefin sends the decrypted data to CyberSource over a secure channel.

 5 CyberSource sends the decrypted data and additional transaction information to your processor.

 

Requirements :

You must have a contractual relationship with Bluefin Payment Systems for PCI-validated P2PE services, which include:

·        Key injection

·        Decryption -  which is performed by CyberSource

·        Hardware

You must manage your Bluefin devices through the Bluefin P2PE Manager portal, which enables you to:

·        Track device shipments

·         Deploy or terminate devices

·        Manage users and administrators

·        View P2PE transactions Download and export reports for PCI compliance

REST API mandatory fields to be used for Bluefin services

·        encryptedPayment_data

·        encryptedPayment_descriptor

·        pointOfSaleInformation.terminalModel

CyberSource owned key management

CyberSource provides Data encryption and decryption services. For certain processor, CyberSource provides Pin decryption services.

Requirements :

You must work with your CyberSource Account manager to exchange BDK and KSN, to encrypt the card data from the terminal.  CyberSource will decrypt the card data.

Sample -

 

 

 

Step 4: EMV Host Validation and Device Certification

Card present certification is classified as a two-step process for host validation and device certification for EMV. Both steps must be completed to have a fully certified EMV solution.

   Host validation

         The testing process is designed to test the capability to carry full chip data correctly in Field 55 and related chip values in existing fields to support EMV contact chip and contactless transactions.   CyberSource is responsible for Host certification.

Device certification

Device certification is also referred as EMV level 3 certification. PTP is responsible for getting device certification. Kindly work with your acquirer processor to get device certified. Device certification overview,

a)      Prerequiste : The processor assigned  EMV analyst requests/ reviews the prereq docs and  checks the solution prior to  test queue.

b)     Onboarding: With assigned analyst, confirm   the scope based on the brand intake forms, identify contacts, get any login credentials and review timelines.

c)      Prep and setup: The technical details for testing are provided, such as merchant & terminal IDs, along with checking basic connectivity. Kindly contact your CyberSource TAM our support team to get your CyberSource MID configured with the processor provided credentials.

d)     Test Execution: Here terminal to host testing begins based on the brand test cases created based on the intake forms submitted to processors. If there are any failure in test cases, kindly contact our support team.

e)     Pre Validation: Test & debug the EMV solution by running the sets of test cases. If there are any test failure, kindly contact our support team. You will submit your test logs to processor analyst.

f)       Validation: Official validation of your test runs that are assessed according to certification requirements. The logs and details are submitted to card brands. Card brands will validate and provide the results.

g)      EMV level 3 approval - EMVco Letter of Approval sent and the solution is officially EMV certified. As part of approval you can work with your processor for production validation by acquiring live processor MID and TID.

h)     Production Roll out – Contact our support team to configure your live MID and TID to process live card present transaction. This step concludes the PTP is ready to accept transaction live.

 

 

Accepted Transaction Types

CyberSource accept all transaction types listed below. Checkout working Card Present API examples on API Reference page. 
Refer our complete DEVELOPER GUIDE to know more about all the transaction type and supported processors.


 


CyberSource through VisaNet (Ctv)

 

Visa Direct Connect (VDC), also referred to as VisaDC, or CyberSource through VisaNet (CtV), is a program that allows acquiring banks to use Visa's network and processing as a replacement for a typical payment processor. When VDC is in place, Visa transactions flow directly to Visa's network, bypassing the need for a payment processor. Other payment types are routed to the appropriate payment networks by Visa just as a 3rd party payment processor would do.

* EMV - EMV is a global standard for exchanging information between chip cards and POS terminals. A chip card is a credit or debit card with an embedded microchip. A chip card also has a magnetic stripe on the back of the card, which can be used for a back-up transaction when the card’s chip cannot be read. The EMV standards define the protocols for all levels of transmission between chip cards and chip card processing devices: physical, electrical, data, and application.

Once you have the right processor coverage:
        - Contact your acquirer to find out whether you are allowed to process card-present transactions.
        - Find out from your acquirer and CyberSource Customer Support whether you must have a separate
            CyberSource merchant ID for your card-present transactions.
        - Contact CyberSource Customer Support to have your account configured to process card-present transactions.

 

Scope for Services 

Transaction Types 

Authorization 

 

Ability to process a final authorization only without a bill/capture request to authorize a card for an amount. The merchant can also request to have the card details tokenized as a CyberSource profile, which can be used for follow-on and card-on-file transactions.

 

merchantTransactionIdentifer is supported in Authorization

Sale (Authorization + Capture) 

A sale is a bundled authorization and capture. You can use a sale instead of a separate

authorization and capture if there is no delay between taking a customer’s order and

shipping the goods. A sale is typically used for electronic goods and for services that you

can turn on immediately or a card present transaction. The merchant can also request to have the card details tokenized as a CyberSource profile, which can be used for follow-on and card-on-file transactions. merchantTransactionIdentifer is supported in Sale

Credit (Standalone) 

When the request for a credit is successful, the funds are taken from the merchant's

account and transferred back to the cardholder. It usually takes two to four days for the acquiring bank to transfer funds from the merchant's bank account.

 

merchantTransactionIdentifer is supported in Credit

Auth Reversal 

Ability to reverse an original authorization from an authorization only or sale request due to the terminal or the partner not receiving a response back for a transaction due to a potential timeout. CyberSource provides merchantTransactionIdentifer field that a partner can specify in the original authorization request. Then if a timeout occurs, the partner can utilize the merchantTransactionIdentifer field (instead of the authRequestID field) to process an auth reversal request, as well as a void request.

Void 

Ability to process a void and authorization reversal through the card terminal if required by the merchant. A void cancels a capture or credit request that you submitted to the system. A transaction

can be voided only if the system has not already submitted the capture or credit request.

merchantTransactionIdentifer is supported in Void

Verbal Auth/Forced Capture 

Ability to obtain a manual authorization code by the merchant calling their processor and processing the sale request with the code. This will process a sale request offline that reflect directly on the merchant batch records. The offline verbal authorization doesn’t process through CyberSource. When you request an authorization through the system, the issuer might ask that you call

the acquirer to answer questions about the transaction. These transaction types are

sometimes known as Referrals.

merchantTransactionIdentifer is supported in verbal Auth

Follow-On Capture  

Ability to process a bill request through CyberSource as a follow-on from the original authorization only request. Follow-on captures can also be processed through the merchant’s server or POS register by sending the request directly to the CyberSource API using the original authorization request ID.

Debit Purchase 

Ability to move money from your customer’s account into your account as a single message request that does not require a subsequent capture.

Debit Credit 

Ability to move money from your account into your customer’s account that is not linked and processed as a single message request.

Debit Reversal 

Ability to reverse either a PIN debit purchase or credit that is linked to the original request ID as a follow-on transaction.

Timeout Reversal (EMV)

In this case, an EMV transaction has not completed successfully due to technical error or timeout. In the cases below, the authorization may or may not have been successful with the processor, but there is no way for the merchant to know. When this happens, the authorizations should be reversed so that funds are released back to the consumer immediately. As a best practice utilizing measured data, 50 seconds is the recommended time by CyberSource for partners to initiate a reversal if no response is received.

The following scenarios should be accounted for by the partner or CyberSource:

 Partner does not receive a response from CyberSource → Partner must query CyberSource to get transaction details, and process an auth reversal if CyberSource has a record of a successful authorization.

 The terminal sent a request but doesn’t acknowledge a response → Partner must query CyberSource to get transaction details, and process an auth reversal if CyberSource has a record of a successful authorization.

 CyberSource receives no response from the processor → CyberSource must process an auth reversal to the processor.

 CyberSource receives a timeout response from the processor → CyberSource must process an auth reversal to the processor.

 

Refund (EMV)

Merchants should be able to process a standalone refund through the card terminal and partner to CyberSource. This case gives the merchant the ability to process the refund request through the terminal, which would include the credit card PAN and EMV block. Note that is it not a follow-on refund request.

Cancellation (EMV)

After an EMV transaction has completed successfully, the consumer may ask for a refund following the sale in-store. Typically, this scenario is catered by a refund, however, the merchant can process this cancellation before the batch cut off by using a CyberSource void plus auth reversal, which requires the card to be provided by the consumer.

Partners initiate the process by first sending a void using the original CyberSource request ID and then initiate an auth reversal request that requires the EMV block to be sent from the terminal.

Timeout Reversal (MSR)

In this case, a MSR transaction has not completed successfully due to technical error or timeout. In the cases below, the authorization may or may not have been successful with the processor, but there is no way for the merchant to know. When this happens, the authorizations should be reversed so that funds are released back to the consumer immediately. As a best practice utilizing measured data, 50 seconds is the recommended time by CyberSource for partners to initiate a reversal if no response is received.

The following scenarios should be accounted for by the partner or CyberSource:

 Partner does not receive a response from CyberSource → Partner must query CyberSource to get transaction details, and process an auth reversal if CyberSource has a record of a successful authorization.

 The terminal sent a request but doesn’t acknowledge a response → Partner must query CyberSource to get transaction details, and process an auth reversal if CyberSource has a record of a successful authorization.

 CyberSource receives no response from the processor → CyberSource must process an auth reversal to the processor.

 CyberSource receives a timeout response from the processor → CyberSource must process an auth reversal to the processor.

 

Refund (MSR)

Merchants should be able to process a standalone refund through the card terminal and partner to CyberSource. This case gives the merchant the ability to process the refund request through the terminal, which would include the credit card PAN. Note that is it not a follow-on refund request.

Cancellation (MSR)

After a MSR transaction has completed successfully, the consumer may ask for a refund following the sale in-store. Typically, this scenario is catered by a refund, however, the merchant can process this cancellation before the batch cut off by using a CyberSource void plus auth reversal, which requires the card to be provided by the consumer.

Partners initiate the process by first sending a void using the original CyberSource request ID and then initiate an auth reversal request with the card data.

Offline transaction / Store & Forward

The partner should have the ability for transactions to be either queued or sent for processing after the consumer has departed when the terminal cannot go online.

Verbal Authorization

When attempting to process a transaction in-store and a processing issue occurs, an associate at the merchant location can call their processor to obtain an authorization code that can be used to process the MSR card-present transaction.

Endless Aisle

This is a case where a customer who is in-store, but is unable to find their item at the location. A merchant associate is able to identify the find the item in another store or distribution center and would like to take the payment in-person to then have the item shipped to the customer’s home.

From a processing perspective, this would require either authorization only (more likely) or sale to be completed from the card terminal while distribution of the item would occur as a separate process. Potentially, the ability to map to a different merchant MID would be required to be passed through.

In person Tokenization

All authorizations and sale requests from the partner to CyberSource must include a call to tokenize the card details. In the authorization response, CyberSource will include a profile token representing the card. This token can then be used for follow-on transactions, such as future authorizations, refunds or other Omni-channel purposes. The partner must pass the token onto the merchant.

 

An example of a common case is a health practitioner who will authorize and tokenize the card details for their customer in-person for the likely amount for a medical visit. The practitioner validates the billing specifics for customer with their insurance carrier. If there’s no change in the amount, then they will bill for the authorization amount. If there are changes in the policy/coverage, then the practitioner can reverse the original authorization and utilize the token generated from the in-person authorization to re-bill for the appropriate amount without having to re-engage the customer.

Optional features – Auth with payment network token

Authorizations with
Payment Network Tokens

You can request a credit card authorization with a payment network token instead of a primary account number (PAN). For information about adding this functionality to an order management system that already uses CyberSource credit card services, see Authorizations with Payment Network Tokens Using the REST API.

 

Balance Inquiry 

Ability to request balance information for an account.

Entry Modes 

Swipe 

 

Support for traditional magnetic stripe swipe on the card terminal. This is a straightforward magnetic swiped transaction through the card terminal by the customer who may not have a chip-enabled credit card. In this case, the partner passes the track data without the EMV block to CyberSource who then forwards to the acquirer.

 

Keyed 

 

Support for manual keyed entry of cards usually by a merchant associate that is  entered on the card terminal directly.

 

In the case of manual key entry, there are two primary use cases to be  accounted for in the solution set.

 A customer calls a merchant location where the associate takes card over the phone and enters the card via the card terminal where the payment is processed as MOTO (card-not-present) using key entry.

 A customer at a merchant location where the card cannot be chip read or MSR read. The customer hands card to associate who can then manually enter card via the card terminal and payment is processed as retail (card-present) using key entry. This assumes the merchant company/store policy allows key entry in-store.

 

Contact EMV (PIN & Signature) 

 

Support for EMV cards using signature cardholder verification, or No CVM which does not require a signature or PIN verification.

Quick Chip – As a Visa company, all EMV solution integrations with partners should support Quick Chip implementations for end-customers. The EMV tag 9F02 will have the final amount when known (as opposed to the predetermined amount). The experience should use a default arbitrary transaction value (dependent by processor) to support the following experience:

§ Insert Card

§ Read the Chip Data

§ Remove Card

§ Present Cardholder with Total

§ Get Issuer Authorization

§ Obtain Signature (is not a No CVM scenario)

 

Contactless 

 

Support for EMV cards using offline or online PIN cardholder verification, or No CVM which does not require a signature or PIN verification.

 

Quick Chip – As a Visa company, all EMV solution integrations with partners should support Quick Chip implementations for end-customers. The EMV tag 9F02 will have the final amount when known (as opposed to the predetermined amount). The experience should use a default arbitrary transaction value (dependent by processor) to support the following experience:

§ Insert Card

§ Read the Chip Data

§ Remove Card

§ Present Cardholder with Total

§ Get Issuer Authorization

§ Obtain PIN (is not a No CVM scenario)

 

American Express ExpressPay, Mastercard PayPass, Visa PayWave. are contactless transaction.

 

Card Types/AIDs 

Visa 

cardType - 001

MasterCard 

cardType - 002

American Express 

cardType - 003

Discover 

cardType - 004

Diners Club ( Processed thru Discover rails)

cardType - 005

Carte Blanche ( Processed thru Discover rails)

cardType - 006

JCB 

cardType - 007

Maestro (International) 

cardType - 042

China Union Pay 

cardType - 062

CVMs  

All CVM 

The Cardholder Verification Method, or CVM, is used to evaluate whether the person presenting a payment instrument, such as a payment card, is the legitimate cardholder.

Offline PIN 

This is a common transaction use case for global consumers and US Debit as cards are issued with PIN preferring CVMs. In this case, the consumers dips their card into the terminal and then provides their PIN to complete the transaction.Pin is offline verified by the terminal

Online PIN 

This is a common transaction use case for global consumers and US Debit as cards are issued with PIN preferring CVMs. In this case, the consumers dips their card into the terminal and then provides their PIN to complete the transaction. Pin is online verified by the acquirer

Signature 

This is a common transaction use case for North American consumers as cards are issued with signature preferring CVMs. In this case, the consumers dips their card into the terminal and then provides their signature to complete the transaction.

No CVM 

In this case, the consumer dips their card into the terminal and the transaction does not require a cardholder validation method after negotiation. This occurs for low dollar amount transactions that carry lower risk. In the US, the typical limits are  $25 for all MCCs (merchant category codes), and  $50 for super market & discount store MCCs.

Fallback to Swiped

If the chip is damaged or the card terminal’s chip reader is faulty, the merchant may fallback to a swiped transaction, while still gaining the liability shift and interchange benefits of an EMV transaction (dependent on acquirer). In this case, the partner passes CyberSource the track data and two additional fields of data (emvRequest_fallback, emvRequest_fallbackCondition), which indicates that the transaction is a fallback scenario.

Fall forward to EMV

In this scenario, the consumer has attempted a magstripe swipe transaction using an EMV enabled card. The response requires that a standard EMV transaction to be performed. CyberSource will respond to the partner with an issuer response code that requires the partner to challenge the consumer for a full EMV transaction. The new transaction should come to CyberSource as a distinct new payment request.

Industry/Commerce Indicators 

Retail 

 

Acceptance for processing in retail locations from the card terminal/solution.

 

Restaurant

Acceptance for processing in Restaurant transactions from the card terminal/solution.

grand_total_amount, gratuity_amount, industry_datatype

MOTO

 

Acceptance for processing mail order or telephone order from the card terminal/solution.

 

Offer level Fields

Offer level fields will provide details on products

These data will provide details on product identifier code , SKU , Quantity and tax amount 

 

EMV Sensitive Fields & Receipt Fields 


EMV Sensitive Fields

According to brand rules and enforce by CyberSource, partners should not the pass the following EMV tags with transaction requests. These fields contain sensitive cardholder data in EMV Field 55 and are not required by CyberSource processing connections.

·        56: Track 1 Equivalent Data

·        57: Track 2 Equivalent Data

·        5A: Application PAN

·        5F20: Cardholder Name

·        5F24: Application Expiration Date

·        99: Transaction PIN

·        9F0B: Cardholder Name (Extended)

·        9F1F: Track 1 Discretionary Data

·        9F20: Track 2 Discretionary Data

For captures, this field is required for contact EMV transactions. Otherwise, it is optional. For credits, this field is required for contact EMV stand-alone credits and contactless EMV stand-alone credits. Otherwise, it is optional. Important For contact EMV captures, contact EMV stand-alone credits, and contactless EMV stand-alone credits, you must include the following tags in this field.

For all other types of EMV transactions, the following tags are optional.

·        95: Terminal verification results

·        9F10: Issuer application data

·      9F26: Application cryptogram

EMV receipt fields

Online Approved/Online Approved, Fallback FIELD

Field Name

Description

Required By

EMV tags

Application Name

The chip card application name used to process the EMV transaction.

Association

9F12

Application PAN

Must be printed on the receipt where the PAN must be truncated to remove any trailing characters and the PAN must be masked.

Association

5A

Card Entry Mode

Indicator how the card information was obtained. Chip Read – Card read from EMV chip. Contactless – Card read by contactless reader. FSwipe – Fallback swipe (insert attempted but failed). Swiped – Card swiped (not fallback).

Processor

-

Transaction Total

The receipt total line amount used to process the transaction.

Association

9F02

Transaction Currency

The receipt total line currency used to process the transaction.

Association

5F2A

Cardholder Verification

The Cardholder Verification Method (CVM) used for the transaction that must be printed on both the merchant and customer receipts.

Processor

-

Authorization Mode

Identifies the mode used to authorize/decline the transaction. Must be identified by the label “Mode”. Issuer – The transaction was sent online and approved/declined by the issuer, or when merchant is standing-in/performing a deferred authorization. Card – The transaction was approved/declined by the card without going online, or was stand-in approved by the merchant after being unable to go online.

Processor

-

AID

Application Identifier

Association

4F

TVR

Terminal Verification Results

Association

95

IAD

Issuer Application Data

Association

9F10

TSI

Transaction Status Indicator

Association

9B

ARC

Authorization Response Code

Association

8A

Authorization Code

The authorization code for the transaction.

Processor

-

Transaction Type

Type of transaction used to process.

Processor

-

Merchant ID

Merchant Identifier

Optional

-

Terminal ID

Terminal Identifier

Optional

-

Signature Line

Cardholder signature line must be printed.

Association

-

 

Offline Declined

FIELD NAME

DESCRIPTION

REQUIRED BY

EMV TAG

Tag 50

Application Label

Processor

50

Tag 5F2A

Transaction Currency Code

Processor

5F2A

Tag 5F34

PAN Sequence Number

Processor

5F34

Tag 82

Application Interchange Profile

Processor

82

Tag 95

Terminal Verification Results

Processor

95

Tag 9A

Transaction Date

Processor

9A

Tag 9C

Transaction Time

Processor

9C

Tag 9F02

Amount Authorized

Processor

9F02

Tag 9F03

Other Amount

Processor

9F03

Tag 9F07

Application Usage Control

Processor

9F07

Tag 9F0D

Issuer Action Code – Default

Processor

9F0D

Tag 9F0E

Issuer Action Code – Denial

Processor

9F0E

Tag 9F0F

Issuer Action Code – Online

Processor

9F0F

Tag 9F12

Application Preferred Name

Processor

9F12

Tag 9F1A

Terminal Country Code

Processor

9F1A

Tag 9F26

Application Cryptogram

Processor

9F26

Tag 9F27

Cryptogram Information Data

Processor

9F27

Tag 9F34

CVM Results

Processor

9F34

Tag 9F36

Application Transaction Data

Processor

9F36

Tag 9F37

Unpredictable Number

Processor

9F37

TAC Default

Terminal Action Code – Default

Processor

-

TAC Denial

Terminal Action Code – Denial

Processor

-

TAC Online

Terminal Action Code – Online

Processor

-

 

 

POS transaction across Globe

Brazil

Need to cover these with REST samples

The merchant_descriptor_postal_code field is required for POS transactions in Brazil. For a description of this field, see the information about merchant descriptors in Credit Card Services for CyberSource through VisaNet Using the SCMP API.

Japan

Need to cover these with REST samples

jpo_jcca_terminal_id Unique Japan Credit Card Association (JCCA) terminal identifier that is provided by CyberSource. The difference between this field and the terminal_id field is that you can define terminal_id, but jpo_jcca_terminal_id is defined by the JCCA and is used only in Japan. ics_auth (O) Integer (13) jpo_jis2_track_data Japanese Industrial Standard Type 2 (JIS2) track data from the front of the card. ics_auth (O) ics_credit (O) String (69)

merchandise_code Identifier for the merchandise. This value must be right justified. In Japan, this value is called a goods code. ics_auth (O) Integer (7)

South Africa

extended_credit_total_ count Number of months over which the cardholder can pay for the purchase. You can use this field when offering extended credit to a cardholder at a retail location. The cardholder provides this value. The issuer pays you for the purchase in one payment, and then the cardholder pays the issuer in the number of monthly payments specified by this value. Note This field is supported only for acquirers in South Africa. ics_auth (O) String (2)

Link the below sample in REST  to respective table content

 

Open Platform card present workflow process

PTP interested in integrating to Open platform card present workflow should follow the below steps

Step 1: Onboarding


Work with CyberSource representatives to get on boarded on CyberSource platform with the processor of your choice. You will receive access to EBC2 Business center to procure REST API keys. 

Step2: Integration with REST APIs

 

REST APIs

Step 1: Create  test merchant with Cybesource.

REST API Authentication

Step 2:  Create  your own API Keys and  understand how to generate API headers.

Developer Guide

CyberSource Payment Services Developer Guides

 Card Present POSTMAN Collection

POSTMAN Collection

Checkout our Card Present specific PostMan Collection

 

 

Step 3:  Terminal Key management option

PTP owned key management

PTP manages data key and pin key encryption and decryption services on their own.

Requirements :

Kindly refer to the REST API fields to construct

 

Bluefin

Bluefin provides PCI-validated point-to-point encryption (P2PE)

 

1. When a customer swipes/ Dips a card through the Bluefin device, the device encrypts the card details at the hardware level and in accordance with PCI P2PE standards.

2. The device sends the encrypted payload to your order management system.

 3. Your order management system sends the encrypted payload to CyberSource in an authorization request or stand-alone credit request.

 4. CyberSource sends the encrypted payload to Bluefin to be decrypted and parsed. Bluefin sends the decrypted data to CyberSource over a secure channel.

 5 CyberSource sends the decrypted data and additional transaction information to your processor.

 

Requirements :

You must have a contractual relationship with Bluefin Payment Systems for PCI-validated P2PE services, which include:

·        Key injection

·        Decryption -  which is performed by CyberSource

·        Hardware

You must manage your Bluefin devices through the Bluefin P2PE Manager portal, which enables you to:

·        Track device shipments

·         Deploy or terminate devices

·        Manage users and administrators

·        View P2PE transactions Download and export reports for PCI compliance

REST API mandatory fields to be used for Bluefin services

·        encryptedPayment_data

·        encryptedPayment_descriptor

·        pointOfSaleInformation.terminalModel

CyberSource owned key management

CyberSource provides Data encryption and decryption services. For certain processor, CyberSource provides Pin decryption services.

Requirements :

You must work with your CyberSource Account manager to exchange BDK and KSN, to encrypt the card data from the terminal.  CyberSource will decrypt the card data.

Sample -

 

 

 

Step 4: EMV Host Validation and Device Certification

Card present certification is classified as a two-step process for host validation and device certification for EMV. Both steps must be completed to have a fully certified EMV solution.

   Host validation

         The testing process is designed to test the capability to carry full chip data correctly in Field 55 and related chip values in existing fields to support EMV contact chip and contactless transactions.   CyberSource is responsible for Host certification.

Device certification

Device certification is also referred as EMV level 3 certification. PTP is responsible for getting device certification. Kindly work with your acquirer processor to get device certified. Device certification overview,

a)      Prerequiste : The processor assigned  EMV analyst requests/ reviews the prereq docs and  checks the solution prior to  test queue.

b)     Onboarding: With assigned analyst, confirm   the scope based on the brand intake forms, identify contacts, get any login credentials and review timelines.

c)      Prep and setup: The technical details for testing are provided, such as merchant & terminal IDs, along with checking basic connectivity. Kindly contact your CyberSource TAM our support team to get your CyberSource MID configured with the processor provided credentials.

d)     Test Execution: Here terminal to host testing begins based on the brand test cases created based on the intake forms submitted to processors. If there are any failure in test cases, kindly contact our support team.

e)     Pre Validation: Test & debug the EMV solution by running the sets of test cases. If there are any test failure, kindly contact our support team. You will submit your test logs to processor analyst.

f)       Validation: Official validation of your test runs that are assessed according to certification requirements. The logs and details are submitted to card brands. Card brands will validate and provide the results.

g)      EMV level 3 approval - EMVco Letter of Approval sent and the solution is officially EMV certified. As part of approval you can work with your processor for production validation by acquiring live processor MID and TID.

h)     Production Roll out – Contact our support team to configure your live MID and TID to process live card present transaction. This step concludes the PTP is ready to accept transaction live.