academe / OmniPay-Payone

A PAYONE gateway driver for the OmniPay framework
MIT License
15 stars 16 forks source link

Update ShopTransactionStatusServerRequest.php #22

Closed DennisDittmann closed 7 years ago

DennisDittmann commented 7 years ago

add handling of missing status responses by PAYONE otherwise static::STATUS_FAILED will be wrongly returned in the missing cases

judgej commented 7 years ago

Merged. Thank you for this.

judgej commented 7 years ago

Before I make a release, do you have any further details about how this would work in practice? For example, an action of "underpaid" comes out as a pending transaction in OmniPay's eyes. I'm not sure whether "underpaid" is as far as the transaction can go, or whether a remaining balance can still be paid, or how the merchant site should handle this (maybe just flagged up to the store owner if it remains pending for too long?). Any examples or arguments as to how each of these actions fit into the overall status would be useful.

DennisDittmann commented 7 years ago

Hello,

thank you for your reply! Please, see https://www.payone.com/ fileadmin/downloads/sonstiges/PAYONE_Platform_Client_API_EN.pdf page 105 ff. for further precise details concerning this topic, too.

We had the following problem:

We got a message by PAYONE like

{"code":"invoice","key":"ca57...","txaction":"appointed"," portalid":"202...","aid":"36...","clearingtype":"rec"," notify_version":"7.4","txtime":"1493212054","currency":"EUR" ,"userid":"100464...","accessname":"","accesscode":"" ,"param":"","mode":"test","price":"52.54","id":{"1":" 1214","2":"-"},"pr":{"1":"44.99","2":"7.55"},"no":{"1":"1","2":"1"},"de":{"1":"Product name","2":"Standardversand"},"ti":{"1":"Product name","2":" Standardversand"},"va":{"1":"19.0","2":"0.0"},"txid":" 222874492","reference":"584","sequencenumber":"0","company": "","firstname":"Holger","lastname":"Payer","street":"F\u00fcrstenstr., 111, 111","zip":"12345","city":"D\u00fcsseldorf","email":"example@example.de ","country":"DE","shipping_company":"","shipping_firstname":"Holger"," shipping_lastname":"Payer","shipping_street":"F\u00fcrstenstr., 111, 111","shipping_zip":"12345","shippingcity":"D\u00fcsseldorf","shipping country":"DE","transaction_status":"completed","balance": "52.54","receivable":"52.54"}

As you can see, especially "txaction":"appointed" was transmitted by PAYONE.

Then, approximately 10 minutes later, we got a message like:

{"code":"invoice","key":"ca57...","txaction":"paid", "portalid":"202...","aid":"36...","clearingtype":"rec"," notify_version":"7.4","txtime":"1493212054","currency":"EUR" ,"userid":"100464...","accessname":"","accesscode":"" ,"param":"","mode":"test","price":"52.54","id":{"1":" 1214","2":"-"},"pr":{"1":"44.99","2":"7.55"},"no":{"1":"1", "2":"1"},"de":{"1":"Product name","2":"Standardversand"},"ti":{"1":"Product name","2":"Standardversand"},"va":{"1":"19.0","2":"0.0"},"txid":" 222874492","reference":"584","sequencenumber":"0","company": "","firstname":"Holger","lastname":"Payer","street":"F\u00fcrstenstr., 111, 111","zip":"12345","city":"D\u00fcsseldorf","email":"example@example.de ","country":"DE","shipping_company":"","shipping_firstname":"Holger"," shipping_lastname":"Payer","shipping_street":"F\u00fcrstenstr., 111, 111","shipping_zip":"12345","shippingcity":"D\u00fcsseldorf","shipping country":"DE","balance":"0","receivable":"52.54"}

In this case "txaction":"paid" was sent by PAYONE.

At this point, the previous evalution of ShopTransactionStatusServerRequest.php led to the problem that "paid" was not evaluated to static::STATUS_COMPLETED but to static::STATUS_FAILED. In turn, this led to the trouble that our shop system (extensions aimeos and aimeos_pay within TYPO3) evaluated the status of the given order to "refused".

(In some cases a third message with "txaction":"invoice" was additionally sent.)

Therefore, we changed the case distinctions in the method getTransactionStatus() within the class ShopTransactionStatusServerRequest.

("add handling of missing status responses by PAYONE otherwise static::STATUS_FAILED will be wrongly returned in the missing cases")

With kind regards, Dennis Dittmann

2017-05-08 13:27 GMT+02:00 Jason Judge notifications@github.com:

Before I make a release, do you have any further details about how this would work in practice? For example, an action of "underpaid" comes out as a pending transaction in OmniPay's eyes. I'm not sure whether "underpaid" is as far as the transaction can go, or whether a remaining balance can still be paid, or how the merchant site should handle this (maybe just flagged up to the store owner if it remains pending for too long?). Any examples or arguments as to how each of these actions fit into the overall status would be useful.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/academe/OmniPay-Payone/pull/22#issuecomment-299842119, or mute the thread https://github.com/notifications/unsubscribe-auth/AbH-2IGtr9WJwBjHum2-BxuDrCO-a7S3ks5r3vwegaJpZM4NR4cr .

judgej commented 7 years ago

Thanks, that helps put it into context. I think a table of the mappings should go into the readme to raise its visibility a bit, as it feels important to know what assumptions are being made. I'll do that now, then make a minor release (since the logic has changed slightly).