Card Present Connect | Electric Vehicle Charging Developer Guide
This section describes how to use this guide and where to find further information.
Audience and Purpose
This guide is written for application developers who want to integrate payment
processing for electric vehicle (EV) charging services. These API services are
available using the REST API.
Implementing these API services requires software development skills and knowledge of
EV charging payment practices. You must write code that uses the REST API request and
response fields to integrate the payment services into your existing EV charging
payment system.
VISA Platform Connect: Specifications and Conditions for
Resellers/Partners
The following are specifications and conditions that apply to a Reseller/Partner enabling
its merchants through
Cybersource for
Visa Platform Connect
(“VPC”)
processing
. Failure to meet any of the specifications and conditions below is
subject to the liability provisions and indemnification obligations under
Reseller/Partner’s contract with Visa/Cybersource.
Before boarding merchants for payment processing on a VPC acquirer’s connection,
Reseller/Partner and the VPC acquirer must have a contract or other legal agreement
that permits Reseller/Partner to enable its merchants to process payments with the
acquirer through the dedicated VPC connection and/or traditional connection with
such VPC acquirer.
Reseller/Partner is responsible for boarding and enabling its merchants in
accordance with the terms of the contract or other legal agreement with the relevant
VPC acquirer.
Reseller/Partner acknowledges and agrees that all considerations and fees associated
with chargebacks, interchange downgrades, settlement issues, funding delays, and
other processing related activities are strictly between Reseller and the relevant
VPC acquirer.
Reseller/Partner acknowledges and agrees that the relevant VPC acquirer is
responsible for payment processing issues, including but not limited to, transaction
declines by network/issuer, decline rates, and interchange qualification, as may be
agreed to or outlined in the contract or other legal agreement between
Reseller/Partner and such VPC acquirer.
DISCLAIMER: NEITHER VISA NOR CYBERSOURCE WILL BE RESPONSIBLE OR LIABLE FOR ANY ERRORS OR
OMISSIONS BY THE
Visa Platform Connect
ACQUIRER IN PROCESSING TRANSACTIONS. NEITHER VISA
NOR CYBERSOURCE WILL BE RESPONSIBLE OR LIABLE FOR RESELLER/PARTNER BOARDING MERCHANTS OR
ENABLING MERCHANT PROCESSING IN VIOLATION OF THE TERMS AND CONDITIONS IMPOSED BY THE
RELEVANT
Visa Platform Connect
ACQUIRER.
Introduction to Electric Vehicle Charging
The
Cybersource
solution for processing electric vehicle (EV) charging
transactions is Card Present Connect | Electric Vehicle Charging. This solution is built
on global standards established by card schemes to ensure reliable, scalable, and secure
processing for card-not-present transactions and EMV contact/contactless card-present
transactions. Magnetic stripe processing should be used only as a fallback payment
method.
Supported Card Types and Entry Modes
These card types are supported for EV charging transactions:
Mastercard
Visa
These entry modes are supported for EV charging transactions:
EMV contact and contactless
Magnetic stripe swipe
Prerequisites
Before integrating
Cybersource
services for EV charging transactions, you
must have these items in place:
Merchant account with an acquirer that is enabled for processing EV charging
transactions on
Visa Platform Connect
.
Cybersource
account for payment services.
Payment technology provider (PTP) that is integrated with
Cybersource
and can perform message-level validation (MLV).
EMV Level 1 certified terminals and EMV Level 2 certified software in
preparation for EMV Level 3 Certification.
Validation and Certification
Work with your payment technology provider (PTP) to allocate time to complete the
message-level validation (MLV) and EMV Level 3 certification with your EV charging
processing system. You must pass MLV before beginning EMV Level 3 certification. You
must complete validation and certification before your system can go live. For more
information, see Prerequisites.
Message-Level Validation
Message-level validation (MLV) is a script-based, field-level validation against
Cybersource
specifications.
Your PTP uses amount-based test triggers to send transactions to a test environment and
the Visa Certification Management System for decryption. The test results are XML or
RESTful output,
Business Center
test transactions, and log prints.
Cybersource
uses these tests to validate the results:
Cross-edit checks
Data element validation
Interchange compliance
Data mapping validation
EMV Level 3 Certification
This topic is an overview of the Level 3 certification with
Cybersource
and
Visa Platform Connect
. For details on how to design an EMV Level 3 certified
payment application, see EMV Book 3 on the EMVCo website: https://www.emvco.com.
Certification
is a formal process that for validating the device and
application compliance with card scheme acceptance requirements. The certification team
uses a brand test tool and simulator. The process includes these elements:
Using a card simulator such as ICC or Fime.
Failed case analysis and resolution.
For Mastercard certification, your PTP submits results to Mastercard and pays
the costs for approved partners that Mastercard uses.
For Visa certification,
Cybersource
submits results to Visa.
Waivers from the card schemes for exceptions.
Card scheme responses or Letter of Approval (LOA) to signify acceptance and
Level 3 certification.
Although the processes and support for Global Card Present Connect projects and
direct merchant and acquirer projects are different, the timelines are essentially the
same.
Card-Present Transaction Risk Control Requirements
Card-present transactions carry lower risk than card-not-present transactions because the
customer and payment card are physically present, which can result in lower transaction
fees. However, acquirers must still apply standard risk-control measures. Acquirers must
monitor transaction activity and manage fraud and disputes in accordance with payment
network rules, including the Global Acquirer Risk Standards. They also must comply with
these Visa risk compliance programs:
Visa Fraud Monitoring Program
Visa Dispute Monitoring Program
To meet risk control requirements, acquirers can use one of these options:
Enable
Cybersource
transaction and fraud monitoring tools.
Ensure that their payment technology partners (PTPs) implement transaction and fraud
monitoring tools.
Deploy their own transaction and fraud monitoring tools.
Each option provides necessary fraud and risk controls for direct merchant relationships
and for PTPs that do not operate their own monitoring solutions.
This section describes the EV charging transaction scenarios supported by
Cybersource
.
Pre-Pay Transaction Scenario
The Pre-Pay transaction scenario for EV charging enables a customer to pay in advance for
the electricity they plan to use when charging their electric vehicle. The transaction
amount is calculated based on the amount of time or number of kilowatts (kW) the
customer chooses at the start of the charging session. When the final cost of the
charging session is less than the estimated amount, an automatic, host-generated partial
reversal request is sent at the time of capture.
Pre-Pay Transaction Workflow
The Pre-Pay transaction workflow for EV charging typically consists of this sequence of
events:
The customer chooses the amount of time or number of kW to charge their electric
vehicle and presents a payment method to pre-pay for the EV charging
session.
The charging session transaction amount is calculated by the EV charging payment
system using the amount of time spent charging or number of kW chosen.
The authorization request is sent to the issuing bank.
The issuing bank approves the transaction and sends an authorization response. A
temporary hold for the authorized amount is placed on the customer's payment
method.
The EV charging session starts. To add more time or kW, the customer must start
a new charging session.
The EV charging session ends when the customer's chosen amount of time or number
of kW is reached. If the charging session ends before the chosen amount of
charging is achieved, an automatic, host-generated partial reversal request is
sent for the unused transaction amount.
A capture request for the final transaction amount is sent to the issuing bank.
When the final cost of the charging session is less than the estimated amount,
an automatic, host-generated partial reversal request is sent at the time of
capture.
Post-Pay Transaction Scenario
The Post-Pay transaction scenario for EV charging enables a customer to pay for the
electricity they use to charge their electric vehicle when the charging session ends.
The final transaction amount is calculated based on the amount of time or number of
kilowatts (kW) used during the EV charging session.
Figure:
Post-Pay Transaction Workflow
The Post-Pay transaction workflow for EV charging typically consists of this sequence of
events:
The customer can choose a specific amount of time or the number of kilowatts
(kW) to charge their electric vehicle or can start a charging session for an
unspecified amount.
The customer presents a payment method to pay for the EV charging session.
The EV charging session starts.
The EV charging session ends when the customer's chosen amount of time or number
of kW is reached, the battery is fully charged, or the customer manually stops
the charging session.
The charging session transaction amount is calculated by the EV charging payment
system using the amount of time spent charging or the number of kW
consumed.
A sale request is sent to the issuing bank.
Flexible Transaction Scenario
The Flexible transaction scenario for EV charging enables an efficient and customer- and
merchant-friendly solution for EV charging transactions. The transaction amount is
calculated based on the amount of time or number of kilowatts (kW) used during the EV
charging session. This transaction scenario has implementation prerequisites. For more
information, see Prerequisites for the Flexible Transaction Scenario.
The Flexible transaction scenario offers these features and benefits:
Real time adjustments to the EV charging session cost. For more information about
this key feature, see the description of
dynamic adjustment capability
below.
Accommodation of variations in charging time and energy consumption.
Customers benefit from more accurate billing based on actual usage.
Merchants benefit from receiving accurate payments for the energy provided and
reduce the risk of unpaid balances or excessive refunds.
A key features of the Flexible transaction scenario is the
dynamic adjustment
capability
. When the EV charging session costs more than the initially estimated
amount, an incremental authorization request is sent to obtain the additional
transaction amount. A merchant can send multiple incremental authorization requests
during the charging sessions to increase the charging transaction amount. When the final
cost of the charging session, including incremental authorizations, is less than the
estimated amount, an automatic, host-generated partial reversal request is sent at the
time of capture.
Figure:
Flexible Transaction Workflow
The Flexible transaction workflow for EV charging typically consists of this sequence of
events:
The customer presents a payment method to start a charging session at an EV
charging station.
The charging session transaction amount is calculated using the amount of time
spent charging or number of kW chosen.
The authorization request is sent to the issuing bank.
The issuing bank approves the transaction and sends an authorization response. A
temporary hold for the authorized amount is placed on the customer's payment
method.
The EV charging session starts.
The final transaction amount is calculated by the EV charging payment system
based on the charging time or kW consumed. When the transaction amount is more
than the initially authorized amount, an incremental authorization is sent to
the issuing bank for the difference between the two amounts.
The issuing bank approves incremental authorization request, when applies.
The EV charging session ends when the battery is fully charged or when the
customer manually stops the charging session.
A capture request for the final transaction amount is sent to the issuing bank.
When the final cost of the charging session, including any incremental
authorizations, is less than the estimated amount, an automatic, host-generated
partial reversal request is sent at the time of capture.
Prerequisites for the Flexible Transaction Scenario
To implement the Flexible transaction scenario for EV charging, your payment system must
have these prerequisite capabilities:
Calculates initial estimated EV charging cost based on average charging duration
and energy consumption.
Monitors real time EV charging progress.
Performs incremental authorizations.
Communicates with payment systems to perform adjustments.
Electric Vehicle Charging Payment Services
This section describes EV charging payment services.
Electric Vehicle Charging EMV and Card Data
You can request these payment services for EV charging with EMV and card data:
Authorization
Incremental authorization
Capture
Reversal
Sale
Void
This table shows which EMV tags are:
M: required
P: prohibited
O: optional
C: conditional (Send the tag when it is present in the card and terminal.)
EMV Data Elements and Tags
Data Element
EMV Tag
Mastercard
Visa
Transaction Date
9A
M
M
Transaction Type
9C
M
M
Transaction Currency Code
5F2A
M
M
Terminal Country Code
9F1A
M
M
Amount Authorized
9F02
M
M
Amount Other
9F03
M
M
Application PAN Sequence Number
5F34
C
O
Application Transaction Counter (ATC)
9F36
M
M
Application Interchange Profile (AIP)
82
M
M
Dedicated File (DF) Name
84
M
M
Terminal Verification Results (TVR)
95
M
M
Issuer Application Data
9F10
M
M
Application Cryptogram
9F26
M
M
Cryptogram Information Data (CID)
9F27
M
O
Terminal Capabilities
9F33
M
M
Cardholder Verification Method (CVM) Results
9F34
M
O
Unpredictable Number (UN)
9F37
M
M
Form Factor Indicator
9F6E
O (Authorization)
P (Refund)
C
Mastercard Authenticated Application Data
9F60
O
Does not apply
Mastercard Kernel Identifier‐Terminal
96
O
Does not apply
Electric Vehicle Charging Transaction Descriptions
Cybersource
recommends that you include a description of the card-present
EV charging transaction type in each transaction request. The descriptions appear in the
Business Center
and in your transaction reports.
Include the EV charging description in the comments request field,
clientReferenceInformation.comments
.
Add this enhancement at your next opportunity and test the field before live deployment.
Making this change does not affect your L3 or MLV status, provided that no other changes
are made.
Contact customer support if you would like
Cybersource
to review tests
that you performed in a test environment after adding the comments request field.
Use the EV charging transaction descriptions shown in the tables to identify request
message types in the
Business Center
.
Pre-Pay Transactions
Service
Card present (CP) or Card not present (CNP)
Comments Field Value
Description
Authorization
CP
Pre-Pay Auth
Authorizes specific amount or duration to start the EV charging
session.
Capture
CP
Pre-Pay Capture
Captures final amount for the charging session.
Capture
CP
Pre-Pay Capture Less Than Auth
Captures final amount for the EV charging session when less than the
authorization amount. Sends automatic, host-generated partial reversal
request for the unused amount when the charging session expires.
Post-Pay Transactions
Service
Card present (CP) or Card not present (CNP)
Comments Field Value
Description
Sale
CP
Post-Pay Sale
Sale for the amount used during the EV charging session when the
customer pays after the charging session.
Flexible Transactions
Service
Card present (CP) or Card not present (CNP)
Comments Field Value
Description
Authorization
CP
Flexible Auth
Authorizes specific amount or duration to start the EV charging
session.
Capture
CP
Flexible Capture
Captures final amount for the charging session.
Capture
CP
Flexible Capture Less Than Auth
Captures final amount for the EV charging session when less than the
authorization amount. Sends automatic, host-generated partial reversal
request for the unused amount when the charging session expires.
Incremental authorization
CP
Flexible Incremental Auth
Requests incremental authorization when final amount is higher than
estimated amount.
Error Transactions
Service
Card present (CP) or Card not present (CNP)
Comments Field Value
Description
Reversal
CP
Error REVERSAL Timeout
Reverses previous authorization request for which a response was not
received. Reversal not used for sale.
Reversal
CP
Error REVERSAL
Reverses previous authorization request. Reversal not used for sale.
Void
CP
Error VOID Timeout
Voids previous sale or capture request for which a response was not
received.
Void
CP
Error VOID Payment
Voids previous payment (sale) within the same day.
Void
CP
Error VOID Capture
Voids previous capture within the same day.
Authentication Requirements for Incremental Authorizations in the European Union
To meet the customer authentication regulatory requirements for incremental
authorizations in the European Union (EU), the recommendation is to set the floor limit
on the terminal to a very low value. When you use a terminal with this setting to
perform a card-present authorization, the Customer Verification Method (CVM) workflow is
initiated. The Strong Customer Authentication (SCA) workflow is not initiated for
incremental authorizations when you use the recommended floor limits on the terminal.
Use this information to process an authorization for a Pre-Pay transaction. For more
information about this payment service, see Pre-Pay Transaction Scenario.
Endpoint
Production:
POST
https://api.cybersource.com
/pts/v2/payments
Test:
POST
https://apitest.cybersource.com
/pts/v2/payments
Required Fields for an Authorization in Pre-Pay Scenario
Use this information to process a capture for a Pre-Pay EMV transaction. For more
information about the Pre-Pay transaction scenario, see Pre-Pay Transaction Scenario.
Endpoint
Production:
POST
https://api.cybersource.com
/pts/v2/payments/
{id}
/captures
Test:
POST
https://apitest.cybersource.com
/pts/v2/payments/
{id}
/captures
The
{id}
is the transaction ID
returned in the authorization response.
Required Fields for a Capture in Pre-Pay EMV Scenario
Use this information to process a sale for a Post-Pay transaction. A sale combines an
authorization and a capture into a single transaction. For more information about this
payment service, see Post-Pay Transaction Scenario.
Use this information to process an authorization for a Flexible transaction. For more
information about this payment service, see Flexible Transaction Scenario.
Use this information to process an incremental authorization for a Flexible transaction.
You can process multiple incremental authorizations for a single EV charging session.
Use this type of authorization when the final transaction amount of the charging session
is more than the amount of the initial authorization. When the final transaction amount
is less than the total authorized amount, an automatic, host-generated partial reversal
request is sent.
Use this information to process a capture for a Flexible EMV transaction. For more
information about this payment service, see Flexible Transaction Scenario.
Endpoint
Production:
POST
https://api.cybersource.com
/pts/v2/payments/
{id}
/captures
Test:
POST
https://apitest.cybersource.com
/pts/v2/payments/
{id}
/captures
The
{id}
is the transaction ID
returned in the authorization response.
Required Fields for a Capture in Flexible EMV Scenario