Proper use of the recurring flag

[judgej]

The use of the recurring flag is a little confusing, and I am not convinced I am using it correctly. It seems to be largely independent of the use of the PKN. This response (thank you Michael) to my question about this flag may help to shed some light:

---

We try to describe the recurring process here: http://api.girocheckout.de/en:girocheckout:creditcard:start#recurring_credit_card_payment

It's probably not very clear, but the essence is that pkn is not equivalent to recurrent. You could make a transaction with a pkn that is not recurrent.

For example, if you used a pkn to store a customer's credit card data, and when he returns to your store you allow him to pay with that card again, without having to reenter his data. In that case he will only have to enter his CVV.

Recurring payment is normally used by backend systems for subscriptions. The system may bill the customer without any intervention at all, using the pkn as well. But in that case the recurring flag needs to be set.

Also it's important to know that in order to be able to use recurring, the merchant needs a special contract with the credit card acquirer authorizing this kind of transactions.

[judgej]

My response:

---

I think you have confirmed the conclusion I have reached. There are three ways a credit card payment can be made:

1. User is redirected and enters all their credit card details. (recurrent = no)

2. User is redirected with a PKN, so only needs to enter their CVV to confirm. (recurrent = no)

3. The back-end system makes a payment for the user. (recurrent = yes, PKN must be set)

I have found that a forth option exists, with a PKN and recurrent = no, but to the "start" endpoint. This causes a user redirect, but they are immediately redirected back with a successful payment having been made, and no user interaction was sought. Is is safe to ignore this forth option? I don't see the need to redirect the user to do nothing, if the server can perform the action server-to-server. UNLESS, it provides some additional security check that may occasionally ask the user for additional details. If so, then I can't ignore it.

When doing a back-end payment with a PKN, it seems to make no different how the recurring flag is set. It can be on or off, and the payment still completes on the test system. Is there any functional different here, or is recurring effectively optional when making a request to the "payment" endpoint with a PKN?

[judgej]

From GiroSolutions:

---

Option 4 is the same as 2. If a PKN is set but recurring=0, the start endpoint should always be used because of the CVV entry and also because depending on the bank there might be additional security mechanisms, such as Secure3D, which may need to be executed. So yes, you need to take that into account.

The recurring field is not optional, as explained in my previous mail. The test system may not reflect this correctly, as this is ultimately dependent on the specific contract the merchant has.

[judgej]

So we have:

1. Not recurrent, no PKN, payment page used: user enters full payment details.
2. Not recurrent, PKN provided, payment page used: user enters CVV only.
3. Is recurrent, PKN provided, payment page used: user enters nothing normally, but with a redirect the gateway can interject additional security checks to interact with the user if it desires to.
4. Is recurrent, PKN provided, NO payment page used: offline payment made.

Notes:

• When no payment page is used, the PKN is mandatory.
• When the PKN is recurrent, the PKN is mandatory.
• For (4), it seems to make no difference whether the recurrent flag is set or not. There may not be a difference, but it is safer to set it, or at least default it to on, just in case. Unless, this is about single-use vs multiple-use PKNs (I did experiment, and it seemed not to be the case though).