Card-Not-Present Transactions

When a customer provides a card number, but the card and the customer are not physically present at the merchant's location, the purchase is known as a card-not-present transaction
. Typical card-not-present transactions are internet and phone transactions. Card-not-present transactions pose an additional level of risk to your business because the customer’s identification cannot be verified. You can reduce that risk by using features such as the Address Verification System (AVS) and Card Verification Numbers (CVNs). The AVS and CVNs provide additional protection from fraud by verifying the validity of the customer’s information and notifying you when discrepancies occur.

Card-Present Transactions

When a customer uses a card that is physically present in a retail environment, the purchase is known as a card-present transaction
.

Authorizations with Card Verification Numbers

Card verification numbers (CVNs) are a required feature for the authorization service.

The CVN is printed on a payment card, and only the cardholder can access it. The CVN is used in card-not-present transactions as a verification feature. Using the CVN helps reduce the risk of fraud.

CVNs are not included in payment card track data and cannot be obtained from a card swipe, tap, or dip.

CVNs must not be stored after authorization.

In Europe, Visa mandates that you not include a CVN for mail-order transactions and not record a CVN on any physical format such as a mail-order form.

Endpoint

Set the

ccAuthService_run

field to

true

.

Send the request to

https://ics2ws.ic3.com/commerce/1.x/transactionProcessor

.

CVN Locations and Terminology

For most cards, the CVN is a three-digit number printed on the back of the card, to the right of the signature field.

For American Express, the CVN is a four-digit number printed on the front of the card above the card number.

Image depicting the location of the CVN on the back of most cards and the front
of an American Express card. — CVN Locations

Each payment card company has its own name for the CVN value:

American Express and Discover call it the Card Identification Number
(CID).

JCB calls it the Card Authentication Value
(CAV2).

Mastercard calls it the Card Validation Code
(CVC2).

Visa calls it the Card Verification Value
(CVV2).

International Transactions

Consider these dynamic currency conversion and merchant remittance funding when processing international transactions.

`Dynamic Currency Conversion`

Dynamic Currency Conversion (DCC) is a service that enables users to conver the price of a transaction from a merchant's local currency to the customer's billing currency in real time. It is regulated by Mastercard and Visa.

The DCC Gateway service allows users to choose thier own service provider for DCC while complying with Mastercard and Visa payment processing rules for DCC transactions. The currency conversion is performed directly between the user and a third-party provider prior to authorizing a network compliant DCC transaction on their processor connection.

Using the DCC Gateway option, you can comply with card mandates and other regulations while using a third-party currency conversion service.

Merchant Remittance Funding

You can request that the transaction proceeds be converted to another currency. Currency conversion uses a foreign exchange rate to calculate the conversion to the requested currency. The foreign exchange rate might be explicitly stated as a rate or implicitly stated as a transaction amount. The funded amount and can vary from day to day. The foreign exchange rate might also include an increase for the foreign exchange risk, sales commissions, and handling costs.

`Token Management Service`

The Token Management Service (TMS) tokenizes, securely stores, and manages customer and payment data. TMS enables you to:

Securely store a customer's payment details and their billing and shipping addresses.

Create a network token of a customer's payment card.

TMS simplifies your PCI DSS compliance. TMS passes back to you tokens that represent this data. You then store these tokens in your environment and databases instead of customer payment details.

TMS Token Types

Customer — Stores the buyer’s email address and the merchant's account ID for that buyer plus any other custom fields.

Shipping Address — Stores a shipping address for a specific customer.

Instrument Identifier — Stores either a payment card number or a bank account number and routing number

This resource creates either:

An Instrument Identifier token using details of a payment card or an ACH bank account.

A payment network token using the details of a payment card; also uses the card expiration date and billing address, which are pass-through only fields.

Payment Instrument — Stores a Payment Instrument using an Instrument Identifier token. It does not store the card number and cannot exist without an associated Instrument Identifier. It stores:

Card expiration date

Billing address

You can also choose to store this information yourself instead and store only the card number or bank account and routing number in an Instrument Identifier object.

Customer Payment Instrument — Creates and stores a payment instrument for a specific customer ID and an Instrument Identifier token.

TMS Features

Create, retrieve, update, and delete tokens.

Set a default payment instrument and shipping address for a customer.

Process follow-on payment transactions with token IDs.

Create and update tokens through bundled payment transactions.

Due to mandates from the Reserve Bank of India, Indian merchants cannot store personal account numbers (PAN). Use network tokens instead. For more information on network tokens, see the Network Tokenization section of the Token Management Service Guide.

Transaction Types