STRONG CUSTOMER AUTHENTICATION (PSD2)

Important notice
DIBS Payment Window (Flexwin) / Card API

  • The COF/mitType parameters are not yet activated. It is possible to send them to Flexwin  / Card API with no failures.
  • Due to acquirer integration dependencies, the 'preAuth' parameter must still be used to store a card for later usage.
    • The 'COF' and 'mitType' will be available in the very near future.
  • It is possible to pass 'ticket' parameter to Flexwin / Card API to process subsequent CIT transaction.
    • Currently CVC must be entered/passed to continue processing the transaction with SCA.


PSD2 (Payment Service Directive)
On September 14, 2019, a new requirement for all online payments is being introduced in the EU, stating that all transactions (with certain exceptions) should be verified by the consumer.

The change is part of an initiative to harmonize European payments and ensure consumers are protected. This requirement is known as SCA - Strong Customer Authentication – and is part of the EU regulation called PSD2 (Payment Service Directive 2).

This means that all remote electronic transactions must have SCA. This includes E-commerce transactions, which might be rejected by Card Issuers if SCA requirements are not complied with.


What does Strong Customer Authentication (SCA) mean for E-commerce?
An electronic transaction will be defined as having gone through Strong Customer Authentication if at least two of the following three factors have been provided by the consumer - as described on https://www.dibspayment.com/sca


How to evaluate whether my transactions need SCA or not?
In order to know what transactions are required to go through SCA or not, you need to identify if your transactions are initiated by the cardholder/consumer (CIT) or the merchant (MIT).

Cardholder-initiated transaction
A cardholder-initiated transaction (CIT) is when the cardholder or consumer plays an active role in the initiation of the transaction. This includes all one-off transactions where the cardholder is actively selecting products or services on your website and proceeding to the checkout.

Merchant-initiated transaction
A merchant-initiated transaction (MIT) refers to transactions where the cardholder plays no active role, commonly referred to as recurring or card-on-file payments. There must be an agreement in place between the merchant and consumer regarding how much should be charged, for what product or service and when. MIT transactions can be charged on a regular or irregular basis. The MIT transaction is initiated by the merchant based on the agreement, see scenario 4B and 5B. The initial transaction and agreement must always be “signed” with SCA - Scenario 4A and 5A – see below table.

See below table to understand which payment flow is relevant for you:

      Consumer details SCA Required Implication: Hosted payment window Implication: API
  Checkout for one-off transactions  
Customer Initiated Transaction (CIT) 1 Single checkout No card saved YES Single payment via payment window Single payment via Card API
2 Customer registrering a saved card No card saved YES Register card via payment window to allow subsequent transactions with SCA. Register card via Card API to allow subsequent transactions with SCA.
3 Returning customer paying with saved card Card on file YES Payment via payment window using
saved card with SCA
Payment via Card API using
saved card with SCA
Cardholder (Consumer) initiated payment allowing merchant to charge saved card at later point in time      
4A Initial payment in a regular series of payments No card saved YES Register card via Payment Window for subsequent merchant initiated transactions on regular basis Register card via Card API for subsequent merchant initiated transactions on regular basis
5A Initial payment in an irregular series of payments No card saved YES Register card for subsequent merchant initiated transactions on irregular basis Register card via Card API for subsequent merchant initiated transactions on irregular basis
Merchant Initiated Transaction (MIT) Checkout with a stored card registrered with mitType  
4B Subsequent payment in the series of regular payments Card on file NO n/a Use ticket_auth or BULK to initiate a subsequent payment
5B Subsequent payment in the series of irregular payments Card on file NO n/a Use ticket_auth or BULK to initiate a subsequent payment


How to implement needed changes for CIT/MIT transactions.

The general approach is:

  • CIT transactions requires SCA
  • MIT transactions does not require SCA

Use DIBS Payment Window to process subsequent CIT transactions with SCA:

  • This is done by sending the ‘ticket’ to the Payment Window.
    • Note: The ticket ID is returned from the initial payment
  • A masked version of the creditcard will be displayed together with the expiry date.
  • The customer must click “Udfør Betaling” to proceed and will be presented for SCA authentication.

HTML Example for subsequent CIT transactions using the ‘ticket’ parameter

<form method="post" action="https://payment.architrade.com/paymentweb/start.action" accept-charset="utf-8">
	<input type="hidden" name="accepturl" value="https://www.yourdomain.com/payment_accepted">
	<input type="hidden" name="amount" value="100">
	<input type="hidden" name="currency" value="DKK">
	<input type="hidden" name="merchant" value="Merchant ID">
	<input type="hidden" name="orderid" value="Order_ID-123">
	<input type="hidden" name="ticket" value="INSERT_TICKET_ID_FROM_INITIAL_TRANSACTION">
	<input type="submit" name="pay" value="pay">
</form>



UseCase descriptions

Below is listed a number of useCases which may help you to understand which changes you need to implement.

One-off / one-time payments: (Scenario 1)

I’m using DIBS hosted payment window (Flexwin) in which customers makes one-time payments, what do I need to do?

  • Make sure 3D Secure and Dankort Secured By NETS (DSBN) is activated by DIBS.

Save card / card-on-file payments: (Scenario 2)

I’m using DIBS hosted payment window (Flexwin) in which customers register their cards (with the parameter preAuth) to save the card in the webshop for easier check-out. I use the ticket_auth.cgi API for processing easy checkout for returning customers. What do I need to do?

  • Make sure 3D Secure and Dankort Secured By NETS (DSBN) is activated by DIBS. And in your own system add the new parameter “COF=Yes” in the initial post towards Flexwin.

Returning customer using a saved card for easy checkout (Scenario 3)

  • Transactions which are processed as “easy checkout” by a returning customer are categorized as CIT transactions and requires SCA. Ticket_auth.cgi can no longer be used for this purpose.
  • Subsequent CIT transactions must be processed via DIBS Payment Window or Card API

Recurring / subscription payments (fixed amount and fixed interval): (Scenario 4A + 4B)

I’m using DIBS hosted payment window (Flexwin) in which customers register their card (with the parameter preAuth) to sign up for a subscription with a recurring payment.

The amount and the time interval of the captures will never change until the subscription for whatever reason is ended. What do I need to do?

  • Make sure 3D Secure and Dankort Secured By NETS (DSBN) is activated by DIBS. The card must be saved with “mitType=RECURRING”, since the subscription does not change in the interval in which it is getting captured.
  • Note: the preAuth parameter will behave as mitType=RECURRING and can still be used.

Recurring / subscription payments (fixed amount but changing intervals): (Scenario 5A + 5B)

I’m using DIBS hosted payment window (Flexwin) in which customers register their card (with the parameter preauth) to sign up for a subscription with a recurring payment.

The amount is fixed but the time interval of the captures will change. - What do I need to do?

  • Make sure 3D Secure and Dankort Secured By NETS (DSBN) is activated by DIBS. Since the subscription will change in the interval in which it is getting captured the new parameter named mitType=UCOF must be added in the initial registration (preauth) of the card.

Recurring / subscription payments (changing amount but fixed intervals): (Scenario 5A + 5B)

I’m using DIBS hosted payment window (Flexwin) in which customers register their card (with the parameter preauth) to sign up for a subscription with a recurring payment.

The amount will change but the time interval of the captures is fixed. - What do I need to do?

  • Make sure 3D Secure and Dankort Secured By NETS (DSBN) is activated by DIBS. Since the subscription has changed in the amount that is getting captured but the time interval of the captures is fixed the new parameter named mitType=UCOF must be added.

Recurring / subscription payments (changing amount and changing intervals):(Scenario 5A + 5B)

I’m using DIBS hosted payment window (Flexwin) in which customers register their card (with the parameter preauth) to sign up for a subscription with a recurring payment.

Both the amount will change and the time interval of the captures will change. - What do I need to do?

  • Make sure 3D Secure and Dankort Secured By NETS (DSBN) is activated by DIBS. Since the subscription will both change in amount and interval in which it is getting captured, the new parameter named mitType=UCOF must be added.

API integration

I’m using Auth.cgi to send the card data to DIBS in order to make a payment or recurring / subscription registration. What do I need to do?

  • Follow the same approach as for the above useCase descriptions.
  • Use the new Card API service instead of auth.cgi

I’m using 3DSecure.cgi to send the card data to DIBS in order to make a payment or recurring / subscription registration. What do I need to do?

  • Follow the same approach as for the above useCase descriptions.
  • Use the new Card API service instead of auth.cgi

Ticket_auth.cgi / BULK

I’m using ticket_auth.cgi or DIBS BULK FTP service to process subsequent transactions. What do I need to do?

  • Ticket_auth.cgi and DIBS Bulk Service can in the future only be used for subsequwnt MIT transactions.
  • No changes are needed for Ticket_auth.cgi and DIBS Bulk Service. The changes is done one the initial transaction.

New parameters to be used for saving a creditcard for subsequent CIT or MIT transactions.

Parameter name

Description

COF

The COF (Card-On-File) parameter is used to save a creditcard to be used for future CIT payments, i.e. payments, which are initiated by the cardholder for e.g. easy checkout. The format must be COF=yes, otherwise the card is NOT saved

Creditcard saved via the COF parameter can only be used for later usage via Payment Window or Card API

Note: ticket_auth.cgi cannot be used for processing future CIT payments initiated with the COF parameter.

Important info: the COF parameter will by time replace the ‘preauth’ parameter.

mitType

The "mitType" parameter is used to save creditcard info for future MIT payments.

Possible values

  • mitType=RECURRING (scenario 4a)
  • Regular subsequent payment with same amount and interval
  • mitType=UCOF (scenario 5a)
  • Irregular subsequent payments with changing amount and interval.

A transaction initiated with the mitType parameter, can be used for future transactions via ticket_auth.cgi or the DIBS BULK solution.

Note: the "preAuth" parameter will default to mitType=RECURRING).

ticket

This parameter is used for processing subsequent CIT payments via the payment window . The ticket ID refers to a previous saved card based on a initial payment processed with the COF or mitType parameter.

The payment window will then display a masked creditcard and expiry date. The customer will need to authenticate with SCA.

This refers to scenario 3

Good to know

  • An initial payment, where the customers card is saved with either mitType=RECURRING or mitType=UCOF – scenario 4A and 5A, can also be used for subsequent CIT transactions with SCA. These must be processed via DIBS Payment Window or Card API.
Do you have a question or need help?
Follow us
DIBS Payment Services
Stockholm +46 (0)8-527 525 00
Göteborg +46 031-600 800
København +45 7020 3077
Oslo +47 21 55 44 00
Close menu