Proper use of the recurring flag about omnipay-girocheckout HOT 3 OPEN

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?

from omnipay-girocheckout.

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.

from omnipay-girocheckout.

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).

from omnipay-girocheckout.