JCB

Additional information

Country specific information:

Card payments process is largely identical across countries.
There are acquirer specific variances which can result in deviations from the standard model detailed above.

Restricted countries.

Iran
Sudan
North Korea
Cuba
Syria

Authorization processing

A card authorization provides you a confirmation that a customer has sufficient funds to purchase the goods or services they are requesting and that their card issuer agrees to honor the payment.

When a consumer makes a transaction, any authorization given is held against the customer‘s credit limit.
When an authorization hold expires it can no longer be used to capture funds (settlement) and you are required to reauthorize the transaction prior to delivery.
As long as the authorization hold is still valid a capture request (settlement) can be made.
When a capture request is executed the authorization hold is converted to a settlement request and the amount in the settlement request is debited from the cardholders account.

When an authorization is not settled in full the outstanding balance of the authorization is still held against the card.
In the above situation the balance available to the cardholder is compromised.
To prevent this situation you would need to void the remainder of the authorization.
Please note the lifespan of an authorization hold depends on the card type, card issuer and any local regulations which may be applicable.
A credit cards authorization hold will vary in length between seven days on a debit card up to potentially thirty days on a credit product – But this is at the discretion of the card issuer.

Pre-authorization or delayed settlement

Pre-authorization or delayed settlement logic is used in retail, travel and entertainment industries (amongst others) and, in this instance, is used when the settlement will take place at a later date than the authorization – for example when settlement is only requested once goods are packed and shipped or when a ‘free’ period is available for instance with an online game.

During the course of action of this transaction type, an authorization hold is imminent;
when authorizing electronic transactions done with a debit card or credit card and holding this balance as unavailable either until you clear the transaction (also called settlement), or the hold is released.

Voids / Cancellations

Used to cancel an authorization that has not yet been captured.
A payment cancellation stops a settlement request from being generated and sent to the acquirer.
The authorization hold however is not cancelled so the reserved funds are still held and the cardholder will have to wait until the authorization hold expires before the funds are available for use again.
The cancellation function is currently only available for cancelling a transaction that occurred during the same business day.
These transactions will be deleted from the settlement request file before it is sent for clearance.
The only transaction type that can be voided via us is a sale transaction (authorization request).
Once a transaction has been sent for capture it can no longer be voided.

Authorization reversal

To fully cancel an authorization and return the funds to the card holder is possible if the merchant is partnered with an acquirer that supports authorization reversals.
Authorization reversals allow the cardholder to regain access to the available funds by enabling the merchant to remove the hold on the funds being held aside by an authorization.
There are two types of authorization reversal:

Full authorization reversal:

Releases the authorization amount the merchant has placed on a cardholder‘s account, when the full authorization amount is no longer required.
This service should be used in situations where it is required to reverse an unnecessary or undesired authorization and normally is just made for large transaction amounts within the travel and entertainment industry.

Partial authorization reversal:

If the capture amount is less than the authorization amount, the merchant can partially reverse an authorization so the settlement amount matches the new authorization amount and the unused card funds can be released.

The only transaction that can be reversed is a sale transaction (authorization request). The reversal message will be sent to the acquirer who will request the issuer to unblock the funds of the cardholder that will never be settled.
Please note that each acquirer may place different restrictions on the conditions that must be met for you to make an authorization reversal. This restriction may also change per region and card type.

Rejections and refusals

We perform extensive checks on the validity of the information received to avoid incurring costs for passing on incorrect/or incomplete requests to its acquirers, printing offices, and so forth.
processing of the files and records may therefore result in records being rejected due to a lack of required data or due to other reasons. Depending on the platform used for the delivery of data, rejections may be both online and offline.
For some rejections, multiple scenarios may be configured to increase the chance of a successful transaction authorization.
Transactions that pass our validity checks but cannot be processed by its service providers are reported back as refused/or rejected transactions.
We will report rejected and refused transactions with reason codes indicating why a transaction was unable to be authorized/or processed.

(Zero) Account verification/validation

Many electronic commerce merchants establish data-on-file accounts for cardholders which are used to pay for future online purchases.
Usually, when the cardholder provides their card number as the method of payment, prior to establishing the account, you can submit an authorization request for a single currency unit, or similar small amount, to verify that the account is legitimate.
Most of these verification authorizations are never submitted for clearing so the funds are held against the account until the authorization expires.

Rather than using an authorization attempt you can also perform zero amount account verification calls.
function allows you to verify the validity of a card account, perform an address verification (where applicable) or card verification value (CVV2) check without submitting an actual authorization request.

Recurring billing/Continuous authority transactions

Recurring transactions are transactions processed at either predetermined intervals (actual recurring) or transactions which utilize card on file stored data – Whilst these are not strictly a recurrent payment they are marked as such to negate checks which would be undertaken on cardholder present transactions (such as CVV).

Key components to this definition include

Cardholder establishes a relationship with you to receive ongoing services or goods until the contractual arrangement is cancelled
Cardholder gives permission to you to bill his account on a recurring basis
Transaction amount may be a fixed amount or may vary with each billing
Future payments occurring on a regular cycle not to exceed twelve months

If you process recurring transactions, the cardholder shall complete and deliver to you a cardholder approval for such goods or services to be charged to his account.
The approval must at least specify the cardholder‘s name, address, account number, and expiration date, the transaction amounts, timing or frequency of recurring charges and the duration of time for which the cardholder‘s permission is granted.

You must obtain an authorization for each transaction:
A positive authorization response for one recurring transaction card sale is not a guarantee that any future recurring authorization request will be approved or paid.

For all initial payments, which will establish a recurring transaction run, you are required to submit the CVV2 .
Subsequent authorization requests must not carry CVV2 as this value cannot be stored so would not be available for a recurring transaction (cardholder not present)
Recurring transactions may not include partial payments for goods or services purchased in a single transaction.
If you process recurring transactions, the recurring indicator must be included in each authorization request as stated in the programmers guide.

Capture

Electronic and/or other forms of payment reports from banks within our network are gathered daily before 09.00 CET. These reports usually contain transactions received by us during the previous day. Payments cleared to an account after the cut-off time will be part of the statement received the following day. The processing of these payment records takes place on the day of the retrieval of the payment information before 17.00 CET.
It will only be reported as paid after the funds have been cleared from our accounts. The clearing time agreed with its banks differs by bank, card type, and currency, and in addition, can vary between 2 and 7 days. Please note that this time span only covers the period between the receipt of the settlement files by the bank and crediting of us; it does not include time involved in processing and reporting the payment by us.

Soft /Dynamic Descriptors

Some acquiring banks offer a functionality where you can submit, on a transaction level, additional fields which will be printed on the cardholder‘s statement to help them recognize the transaction when reviewing their statement.
This capability is referred to as Dynamic/or Soft Descriptors.
Soft Descriptors allows you to dynamically submit a unique descriptor and a toll free support number for each transaction.
The descriptor and toll free number will transcend through the transaction and be posted on the cardholder's printed statement.
You can use this feature to subdivide a single website into multiple departments, each with a unique description and consumer support telephone number, making it easier for the Consumer to identify transactions.
We rely on the issuers for the presence of the descriptor data.
Dynamic descriptors are more common in the US then in Europe.

We recommend including your URL and the product the consumer just purchased for clarity sake. If possible also include in the descriptor a local customer service phone (toll free) so consumers feel confident.

Please note that although we will try to maximize the functionalities supported on its own platform, this does not necessarily mean that it will be available regardless of the bank used for acquiring: every acquiring bank has its own set of functionalities.

Chargebacks

Credit card and debit cards do not offer a guaranteed form of payment for goods or services.
Each transaction undertaken is subject to return by a card issuer even when authorization has been obtained and all standard sales procedures outlined in the "merchant operating instructions and agreement" have been followed.
The process of returning a transaction unpaid is known as a chargeback.

The Card Schemes define the chargeback process.
Liability for a chargeback must be accepted unless it can be proven that the chargeback is invalid in accordance with Card Scheme rules.

The process starts when the acquiring bank notifies us of the request for information (also known as retrieval request) by the cardholder. We will check if there has already been a refund processed for the transaction in question. If there has been one, the request for information will, at this stage, be sent back to the acquiring bank stating ―already refunded. No further action should be taken.
If no refund has been processed, but a retrieval request is received before 09.00 CET, the request is logged and forwarded to you on the same business day (by email with a request for more information, for example, signed order form) with a response time deadline (typically 5 days) to provide proof of the cardholder‘s authorization of the transactions/acceptance of goods.
You may forward additional information to us by email and we will forward this by email directly to the acquiring bank.

If the additional proof of information is sufficient for the judgment of the acquiring bank and in accordance with the schemes rules, the specific chargeback will not be executed. In this case, we do not receive any further information from the acquiring bank regarding this transaction. Alternatively, if the provided information is insufficient, the specific chargeback will be executed. In this case, our account will be debited as a result of the following steps.

We will receive a notification stating that the cardholder has been refunded by the card issuing bank.
The card issuing bank will debit the account of the card acquiring bank.
The card acquiring bank will debit the account of us.

In the case of a reversed card transaction, we will be debited without prior notification.
We will pass on the debit to you.
You can dispute the chargeback with us. We will dispute the transaction with the acquiring bank. This dispute may result in a withdrawn chargeback and we will pass on the credit back to you. Transactions that have been successfully represented (credited back; withdrawn) can currently only be reported outside of the normal reporting tools.

Processing of reversed transactions runs parallel to the processing of payments (in other words, the information is gathered before 09.00 CET and processed before 18.00 CET). For reversals that cannot be matched to a payment, we will inquire with the bank that generated the debit. If the reversal remains unmatched, it will be removed after 1 full calendar month.

Retrieval request

In some cases, before a chargeback is initiated, the card issuer will request a copy of the sales draft, via a request for information (or retrieval request).
We will forward this request to you. You must respond to this request within the time frame and manner set forth in the request. We will then forward your response to the acquirer. If you fail to timely respond, we will notify the acquirer –we do not notify the acquirer that there is no response to the request for information and a chargeback is often the result of a failed response.

We suggest you follow these recommended procedures to avoid chargebacks:

Using 3D secure for internet transactions, obtain the 3 digit Card Verification Code (CVV2), and/or Address Verification Services (AVS). While transactions using AVS may still be disputed, the service may alert you to certain fraudulent transactions.
Always obtain a signed proof of delivery for shipped merchandise.
Obtain the cardholder‘s account number, name and address with city and state. At the time of the transaction advise the cardholder of any extra cost that they are responsible for (shipping, handling, insurance, etc.).
Confirm the account number provided by the customer by repeating the number back to the customer.
Obtain the required data elements in the folio/registration documentation for a GNS (Guaranteed No Show) Transaction.

In order to process disputes and request for information transactions, we need a clear and legible copy of the sales draft containing the following information (obtained from your files):

Case ID
Dates of sale / credit
Cardholder‘s account number, name and signature in the proof of delivery (if applicable)
Total amount of the sale and description of goods and services; and
Date and authorization approval code

Below is the list we use as recommendations for responses to RFI's. Your business trading name and town (where the transaction took place)

Transaction date
Value
Authorization Code & timestamp (if applicable)
A copy of the sales receipt
Proof of delivery preferably signed by a card holder
Refund receipt / voucher (screen shot of refund processed)
Any other documentation signed by a card holder
Any terms and conditions given to the customer at the time of the sale e.g. limited returns policy.
Card details (GC)
Card Holder name
If processed in accordance with 3D protocol – the 3D MPI log should be provided
URL of your website

The requested information should be emailed to us for processing.

Security services

Fraud prevention and detection tools are designed to complement each other and work together as multiple services that can help you to better combat fraud.

Address Verification Service (AVS) verifies the credit card billing address of the customer who is paying with a credit card. You need to include an AVS request with the transaction authorization and you will receive a result code (separate from the authorization response code) that indicates whether the address given by the cardholder matches the address in the issuer‘s file. A partial or no-match response may indicate increased fraud risk. AVS services are currently available in the UK and the US.

Card Verification Value 2 (CVV2) is a three or four-digit code that is printed on the signature panel of all credit cards.
MOTO and Internet merchants use CVV2 to verify that the customer has a legitimate credit card available at the time of the order.
You can request the customer for the CVV2 code and send it to the issuer as part of the authorization request.

3D Secure offers an extra level of security for online transaction authentication. It is an innovative service that verifies cardholder identity in real-time so customers can shop more confidently. Also, Internet merchants can accept credit cards with peace of mind while authenticating a cardholder‘s identity at the time of purchase.

Disadvantages of cards:

Higher propensity for fraud compared to other payment methods
Ability to reverse / chargeback a transaction
Cross border fees may apply when transacting with overseas merchants (dependent on issuer location)

References

Refunds

Card payments can be refunded upon requested to the card used to make the original transaction. The request can be made through the payment console or via an API call. It is also possible for a transaction whilst in the process of being refunded to still be reversed and a chargeback made by the Consumer. The issuing bank will only accept the claim in cases where the refund hasn’t been fully processed.

Refunds can only be accepted if:

the original transaction was collected through us
The refund value does not exceed 100% of the value of the original transaction.
The merchant category code is not 7995 (Betting (including Lottery Tickets), Casino Gaming Chips, Off-Track Betting and Wagers). 7995 refunds can only be made via a bank transfer or, for payouts merchants can request a CFT/OCT account.

A few general rules apply:

We may reject refund requests if the value of the refund exceeds 100% of the value of the collected transactions.
A refund can be initiated (submitted) as individual transaction, online through the payment console or via an API request.
Refunds have to be accompanied with the original transaction reference number.

Partial refund

When a partial refund needs to be applied, the lower amount can be send within the API-call or through the payment console. Partial refunds are often used when multiple products/services are bought by the consumer and one of the products or services is returned.