ThreeDSConfig

Configuration data for 3ds authentication

Caution

For full details consult EMVCo 3dsecure documentation https://www.emvco.com/emv-technologies/3-d-secure/

Note

Not all data items are requried

Tip

Adding more data items should yield more frictionless transactions

RequestorAuthenticationInd

typically 01 - for other values please consult for assistance
01Payment transaction
02Recurring transaction
03Instalment transaction
04Add card
05Maintain card
06Cardholder verification as part of EMV token ID&V
07Billing Agreement

RequestorChallengeInd

typically 01,03 - for other values please consult for assistance
01No preference2.1.0 2.2.0
02No challenge requested2.1.0 2.2.0
03Challenge requested (3DS Requestor preference)2.1.0 2.2.0
04Challenge requested (mandate, e.g. required for PSD2 compliance)2.1.0 2.2.0
05No challenge requested (transactional risk analysis is already performed)2.2.0
06No challenge requested (data share only)2.2.0
07No challenge requested (strong consumer authentication is already performed)2.2.0
08No challenge requested (utilise whitelist exemption if no challenge required)2.2.0
09Challenge requested (whitelist prompt requested if challenge required)2.2.0
90Enable the Cartes Bancaires Scoring Service (Cartes Bancaires only)2.1.0

Note

On async and hosted payments PayLolly forces 04 (challenge mandated) only on the registering payment: a customer present payment (CIT) with recurrence OneClick, the one that creates a stored card or an agreement. Every other payment uses the value you configure (or the default). Payments that used to be forced to 04 because they were Recurring or Unscheduled CITs now use your configured value.

TransType

typically 01 - for other values please consult for assistance
01Purchase of goods or services
03Check acceptance
10Account funding
11Quasi-cash transaction
28Prepaid activation and load

3DS recurring

please consult us
the registering payment (recurrence OneClick, initiation CIT) always gets a mandated challenge, see RequestorChallengeInd above
differentiate between CIT(initial) and MIT(triggered)
see values

  • recurringExpiry
  • recurringFrequency
  • supply requestorPriorAuthenticationInfo

Derived from the agreement (async and hosted)

When the registering payment carries a Scheduled agreement, PayLolly fills the recurring fields of the authentication request from the schedule, so you do not set them:

Field Value
RequestorAuthenticationInd 03 (instalment) when the schedule has instalments, otherwise 02 (recurring)
RecurringExpiry agreement.expiresAt, or else the date of the last instalment (from firstPaymentDate, or today)
RecurringFrequency minimum days between payments, using 1 day, 7 days, 28 days per month and 365 days per year, so it is never longer than your real interval (at most 9999)
PurchaseInstalData the number of instalments

The derived values win. A different value in your ThreeDSConfig is not refused, only counted. Agreements without a schedule (OneClick) get nothing derived: send a realistic RecurringExpiry yourself if you set indicator 02 or 03, and never a far-future placeholder such as 99991231, which an issuer may reject. A variable amount or frequency can only be signalled from 3DS 2.3.1.

Later merchant initiated payments are not authenticated; they refer to the registration through the scheme reference (Trace ID) that PayLolly stores with the agreement.

Prior authentication on a stored card (async and hosted)

A customer present payment on a stored card that does not register an agreement (for example a returning customer who is not asked for consent again) tells the issuer how the cardholder was authenticated when the agreement was registered, which helps it approve frictionlessly. PayLolly fills RequestorPriorAuthenticationInfo from the agreement's stored evidence: the method (01 frictionless, 02 challenge), the time of the authentication, and the ACS and directory server transaction ids (the latter are only used on 3DS 2.3.1; they are dropped on earlier versions).

The agreement must be named explicitly, nothing is guessed:

  • async: send the agreementId with the stored card's tokenData;
  • hosted: send the same agreement object as when the card was registered (the agreement is found by the card, the cardHolder.reference and the agreementRef).

An authentication that was only attempted (A) is not referred to, nor is one whose method is not known. A RequestorPriorAuthenticationInfo that you send yourself is never replaced. A stored card payment for which no agreement with evidence is found is only counted. The 3DS API and 3DS JS calls are not changed: copy the values from Agreement/Get (threeDS) into your request.

Zero amount (card check)

A payment with amount 0 is sent as a non-payment authentication (message category 02) with indicator 04 (add card), or the recurring indicator above for a scheduled agreement (free trial, purchase amount 0). A configured RequestorAuthenticationInd is ignored for it, because the payment indicators are not valid for a non-payment authentication. Not every issuer supports non-payment authentication: when it does not, the authentication fails with reason 20, and the payment follows the usual 3DS rules of your account.

3DS frictionless

for frictionless to have maximum effect, 3DS additional data should be provided

  • requestorAuthenticationInfo
  • requestorPriorAutenticationInfo
  • riskIndicator
  • acctId
  • acctInfo