Skip to content
Netaxept
    Operational status

    SCA requirements according to use cases

    How to comply with PSD2 SCA rules might depend on the business model in place. This article lists possible scenarios and how they are affected by SCA restrictions.

    Payment without saving card details

    Use case: Customer enters card details in the checkout and pays the purchase. Card details are not saved.

    Here SCA is required on every transaction. Ensure 3D Secure (or equivalent) is activated for your business. Netaxept redirects your customers automatically to SCA after you have performed the Terminal call.

    Easy payment

    Use case: Easy payment: Card details saved for faster checkout next time.

    • Initial transaction (either just card registration with amount: zero value or an actual purchase): SCA is required. Ensure that 3D (or equivalent) is activated for your business. Netaxept redirects consumer automatically to SCA after you have performed the Terminal call.

    1. Register call: updateStoredPaymentInfo="true" to just register the card (if omitted, the actual purchase is made).

    2. Terminal call: to redirect consumer to terminal and get SCA triggered.

    3. Process call: operation="VERIFY"for account verification OR operation="AUTH"with Process(CAPTURE) (or Process(SALE)) to follow.

    4. Query call: to fetch token / `panHash``

    • Subsequent transaction (Returning customer pays with saved card with or without CVV/CVC security code): SCA required. Ensure 3D Secure (or equivalent) is activated for your business.

    To get consumer redirected to SCA, send recurringUse3DS="true" in the Register call in each subsequent transaction, and perform the Terminal call after the successful Register call.

    For CVV/CVC entry, send serviceType="B" or "M".

    1. Register call: recurringUse3DS="true" - redirection to SCA recurringType="S" - Easy payment panHash=[stored token] serviceType="B" - terminal displayed for CVV/CVC entry OR serviceType="M" - terminal bypassed, no CVV/CVC entry

    2. Terminal call: to redirect consumer to terminal and get SCA triggered.

    3. Process call: operation="VERIFY"for account verification OR operation="AUTH"with Process(CAPTURE) (or Process(SALE)) to follow.

    Recurring payments (CoF)

    Use case: Card details saved for subscription payments done with same amount and frequency. Amount and time interval are fixed and won't change over time

    • initial transaction (either just card registration with amount: zero value or an actual purchase): SCA required. Ensure 3D Secure (or equivalent) is activated for your business. Netaxept redirects consumer automatically to SCA after you have performed the Terminal call.

    To make sure Issuer doesn't apply exemption and thus leave your initial transaction without SCA, send force3DSecure="true" with the Register call.

    1. Register call: force3DSecure="true" - SCA required to complete transaction updateStoredPaymentInfo="true" to just register the card (if omitted, the actual purchase is made). recurringType=R- card details get saved for recurring payments. recurringFrequency="X" recurringExpiryDate="YYYYMMDD"

    2. Terminal call: to redirect consumer to terminal and get SCA triggered.

    3. Process call: operation="VERIFY"for account verification OR operation="AUTH"with Process(CAPTURE) (or Process(SALE)) to follow.

    4. Query call: to fetch token / panHash

    Charge a saved card with the same amount and time frequency according to the agreement made with the consumer. SCA not required. To get SCA bypassed, send recurringType="R" and serviceType="A" or "C" in the Register call in each subsequent transaction, skip the Terminal call and continue with the Process call after the successful Register call.

    1. Register call: recurringType=R- indicates recurring payments panHash=[stored token] serviceType="C" - terminal is bypasssed OR serviceType="A"- terminal bypassed, required for app payments, but recommended to be used also for other non-callcenter payments

    2. Process call: operation="AUTH"with Process(CAPTURE) (or Process(SALE)) to follow.

    Merchant initiated transactions

    Use case: Merchant initiated transaction (excl. recurring payment) Card details saved for future payments done with changing amount and/or frequency.

    -initial transaction (Consumer saves card details for later charges initiated by merchant. The first transaction can be either a card registration only (account verification with zero-value) or the actual purchase.)

    SCA required. Ensure 3D Secure (or equivalent) is activated for your business. Netaxept redirects the customers automatically to SCA after you have performed the Terminal call. To make sure the issuer doesn't apply exemption and thus leave your initial transaction without SCA, send force3DSecure="true" in the Register call.

    1. Register call:

    force3DSecure="true" - SCA required to complete transaction

    updateStoredPaymentInfo="true" - to just register the card (if omitted, the actual purchase is made).

    recurringType=S- card details get saved for MIT transactions OR

    recurringType=R- use this only if you have an existing recurring solution and you are in a process of changing it to PSD2 compliant.

    2. Terminal call:

    to redirect consumer to terminal and get SCA triggered.

    3. Process call:

    operation="VERIFY"for account verification OR

    operation="AUTH" with Process(CAPTURE) (or Process(SALE)) to follow.

    4. Query call:

    to fetch panHash=[token]

    • subsequent transaction (Merchant charges saved card with the changing amount and/or time frequency according to agreement made with the consumer.):

    SCA not required. To get SCA bypassed, send

    recurringType="M", recurringTransactionType with the valid value and

    serviceType="A" or "C" with the Register call in each subsequent transaction.

    Skip the Terminal call and continue with the Process call after the successful Register call.

    1. Register call:

    recurringType=M- indicates MIT transaction

    recurringTransactionType= 1 - UCOF OR 2 - Delayed charge OR 3 - No-show

    panHash=[stored token]

    serviceType="C" - terminal is bypassed OR

    serviceType="A"- terminal bypassed, required for app payments, but recommended to be used also for other non-callcenter payments

    2. Process call:

    operation="AUTH" with Process(CAPTURE) (or Process(SALE)) to follow.

    Call center

    Use case: Payment through call center: (Consumer calls to the merchant and gives card details via phone. Merchant representative initiates the transaction.) SCA not required. Call center transactions (MOTO) are out of scope of SCA. Payments created through Netaxept Admin's call center page are automatically marked as MOTO and SCA is bypassed. Transactions are passed directly to authorization after merchant representative has entered card details.

    Was this helpful?

    What was your feeling about it?