is orderId supported for recurring payments?

[MartinMekhaiel]

Thanks for the response! regards

[judgej]

Do you mean the orderNumber?

If so, then I believe so. I have mapped the transactionReference to the orderNumber, and that can be used for capturing, voiding and refunding transactions. However, I have not touched the recurring payments functionality yet. It should be simple and quick to do, but I wanted the core Omnipay functionality in first (authorize, purchase, void, capture, refund).

[judgej]

Looking at it, it seems a recurring payment is an extension of a regular payment or authorisation.

[MartinMekhaiel]

exactly, but you have to pass the orderNumber when doing a recurring payment

[judgej]

Started work on this, and pushed a dev snapshot to dev-master.

The recurring payments need an originalOrderNumber and also need to be able to accept an optional pre-fetched orderNumber for the new order that will result.

I'm also a little unclear about the transactionIdentifier values. For an original order auth to be recurred, it must be given the transactionIdentifier of INITIAL, which is clear. If it is SINGLE then it cannot be recurred.

Now the backend recur transaction can take a transactionIdentifier of SINGLE, INITIAL or RECUR. It seems that if it is INITIAL then that transaction itself can then be recurred. If this happens, then you must cancel the auth on the original transaction, otherwise you can block up the user's account with a series of long-lasted authorisations. Now the SINGLE and RECUR I don't understand. So far as I can see they both do the same thing - take another payment or make another auth, without themselves becoming another recur-capable transaction. Maybe RECUR is just the next in an endless series of regular payments, keeping the original auth open, and SINGLE is the final payment, closing the auth as it is created? Not sure, needs some more investigation.

[MartinMekhaiel]

Hi !

I just reviewed the Docs found here: https://guides.wirecard.at/back-end_operations:transaction-based:recurpayment

and had a quick talk on the phone with the wirecard support:

Here are my foundings:

1. It seems that there are four transactionIdentifiers: SINGLE, INITIAL, RECUR and FINAL.

SINGLE = "Single Payment - not recurring" INITIAL = "Inital Payment - recurring payments will follow" RECUR = "Recurring Payment - a payment within a series or recurring payments" FINAL = "Final payment of recurring payments - does the final payment and closes the recurring series"

2. transactionIdentifier has only to be passed within recurring payments. If transactionIdentifier is not set -> "Single" will be set by default from wirecard.

3. For recurring Creditcard Payments its not necessary to set the transactionIdentifier.

4. For recurring Sepa and Paypal Payments you have to pass a valid Enumerated transactionIdentifier.

5. For recurring SEPA payments a mandateId and mandateSignature CAN be set as optional params. (if not - a new mandateid and mandateSignature are set from wirecard for each payment)

if you use wirecard bank as acquirer: optional : you can set a DueDate for the SEPA recurring payment.

But Attention : From the Docs -> If you choose Wirecard Bank as your acquirer, you can calculate the due date yourself. Wirecard requires from you to submit recurring and final direct debit payments four (4) banking days before the due date.

6. Also for recurring Paypal payments - 3rd Party Commission have to be activated: https://guides.wirecard.at/payment_methods:paypal:setup_3rd_party_permissions

7. If you want to use recurring Payments with SOFORT Its possible, the recurring payments are handled with SEPA.

The initial payment has the be flagged with transactionId = INITIAL The recurring payment has to be flagged with transactionId = RECUR or FINAL also the originalOrderiD has to be passed, and obviously payment-type SEPA has to be selected.

Wirecard knows then from the orignalOrderId which IBAN and BIC to use. Attention: orderIds are stored only 400 days!

[judgej]

I have finished support for recurring payments in this branch:

https://github.com/academe/Omnipay-Wirecard/tree/reorganise

I have done some reorganising in there too, and want to add some more tests before merging in to master, but you may be able to try it out in the meantime. I'm just on the way out of the office and just spotted your comment, but have no time to read in detail. Will do so this evening - thanks for details. That FINAL makes total sense, and I'm not sure why I have missed that in the online docs.

[judgej]

Found this here:

The transaction type “final” defines the last transaction of a series of transactions. After a final payment has been processed for a mandate, it is not possible to generate more transactions for that mandate. At the moment Wirecard does not support final transactions. Please set your transaction to RECUR instead.

Are those docs out of date now?

[judgej]

So credit card payments are automatically always recurring, even when not required? That's how Sagepay works, and I always thought that was weird. It's like once you have taken one credit card payment, you can can keep taking further payments of any amount on the back of that original payment.

That's how I read point 3:

For recurring Creditcard Payments its not necessary to set the transactionIdentifier.

Do we need to enforce this in the driver, so if the payment type is a credit card, the transactionIndentifier is not sent, regardless of what it was set to? If the gateway just ignores it, then we should be okay to just let it be sent.

[MartinMekhaiel]

Oh, okay havent seen that - and also the didnt mention it on the phone.

I suppose the docs are correct, but im gonna verify that tomorrow with a quick call.

Thank you so much for your amazing work, saves us a ton of time.

[MartinMekhaiel]

So credit card payments are automatically always recurring, even when not required? That's how Sagepay works, and I always thought that was weird. It's like once you have taken one credit card payment, you can can keep taking further payments of any amount on the back of that original payment.

Thats correct, at least thats what i got told on the phone. I will re-verify that again tomorrow when i call them.

[judgej]

I've merged the reorganisation branch, with the recur support, into dev-master. If you are in a position to try it out, that would be very helpful. It works for me on the test gateway account, but I've not got a live account to try it on.

[MartinMekhaiel]

thanks! will test it tomorrow

[MartinMekhaiel]

Hi, i just verified now with wirecard on the phone.

• transaction identifier FINAL should not be used anymore, only RECUR, INITAL and SINLGE
• for credit card recurring payments its not necessary to set the transaction identifier , defaults to single.

[judgej]

Thanks. I have updated the documentation with details on how the Seamless side is used. When it involves JavaScript, it is always a lot more difficult to document, since the front end is still a bit like the Wild West at the moment with a hundred different ways to achieve everything and fit into the JS framework-of-the-day.

I think the recurring payments need a state digram to show how they work. The normal transaction states do too (I've sketched that out roughly here.

It kind of helps to fill in the gaps in understanding, assuming you can decipher my terrible handwriting.

[MartinMekhaiel]

Sorry, it will take us some more days to test - will get back to you asap - thanks again!

[MartinMekhaiel]

Hi jason, im sorry that it took ages, recurring payments seem to work in WCP! thank you

[judgej]

Thanks for letting me know. Gave me a nudge to release the draft release version 2.2.0 with some documentation updates in 2.2.1.