academe / omnipay-girocheckout Goto Github PK

@thommyhh @judgej @barryvdh @JamesNuttall

Hello Team,

I am getting "invalid hash response despite creating the hash using the merchantId, projectId, and projectpassword.

Response:

{
"reference": null,
"redirect": null,
"rc": 5002,
"msg": "hash ungültig"
}

This driver is being built initially for Omnipay 2.x for legacy systems.

Once fully built, it will be branched to allow for continued support, but the master branch will continue down the Omnipay 3.x route.

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.

The payment methods are to be built in the following order:

1. CreditCard
   • Authorize
   • Purchase
   • Capture
   • Refund
   • Void
   • Query Pseudo Card (PKN Info)
   • Recurring (repeat) transaction)
2. PayPal
   • Purchase
3. DirectDebit
   • Authorize with payment page
   • Authorize without payment page
   • Purchase with payment page
   • Purchase without payment page
   • Capture
   • Refund
   • Void
   • Query Pseudo Card (PKN Info)
4. Giropay
   • Authorize (not sure if this is available)
   • Purchase (initialise)
   • Check bankstatus
   • Giropay issuer bank query
   • Retrieve sender information
   • Bank selection widget (not a message, perhaps a helper)
5. Paydirekt
   • Authorize
   • Purchase
   • Capture
   • Refund
   • Void
6. iDEAL
   • Purchase
7. EPS

iDEAL and EPS are not used in Germany, so are taking a lower priority.

The PaymentPage payment type supports multiple payment types, selectable by the user.

• Get Transaction message (covers all payment types)

If a card reference is being created when authorizing (by setting the createCard flag) then the card reference must be fetched as a separate request for all payment types except Payment Page.

This change is needed to avoid the need to make that second, explicit API call. During CompleteRequest::send() an API call is made to fetch the card details and supplement the data already returned to the merchant site with the end user. The createCard option needs to be set when completing the transaction in order to trigger this functionality.

The automatic discovery of a driver depends on the root namespace part being Omnipay. There is a workaround using the full path, but it is a little ugly, so we'll just change the root namespace for consistency with just about every other Omnipay driver ou tthere.