Better documentation for notification

[MHaendel]

Nice to see this implemented, but the documentation is lacking. I found no way to integrate this, I use omnipay with the bridge in payum, and without notification I need to rewrite gateways to payum.

[delatbabel]

The structure of each notification message will vary from gateway to gateway. You need to check the gateway plugin documentation for each gateway to see the documentation for notifications.

I'm aware that it's there for both PaymentWall and MultiCards, not sure about the others.

[barryvdh]

Is this related to #327 ?

[MHaendel]

It seems no gateway has implemented the notification interface, are notifications even useable yet with omnipay bridge?

[barryvdh]

No, what Iinked is a suggestion for the upcoming v3, but is that what you mean?

[MHaendel]

This sounds like it is

[w3guy]

@MHaendel my 2checkout driver has the notification interface implemented. see https://github.com/collizo4sky/omnipay-2checkout/blob/master/src/Gateway.php#L107

[judgej]

PAYONE and Sage Pay Server, both use the notification interface. I've added some documentation on how Sage Pay uses it and also how PAYONE uses it. My hope is that some of that will be useful where it is common between all the notification callbacks.

Also if the way these callbacks are used does not look right, or would not work for other gateways, then shout and we can look at fixing that.

Note: Sage Pay also still has the legacy ServerCompleteAuthorizeRequest/Response classes for handing the notifications, but we should stop using that. The "Complete" classes are for handling the return of a user to the site rather than back-channels.

[makasim]

. I found no way to integrate this, I use omnipay with the bridge in payum, and without notification I need to rewrite gateways to payum.

FYI For the reference Payum/OmnipayBridge#28

If you think the notify action could be improved or it does someting not omnipay way please let us know.

[judgej]

I believe Payum handles the storage and sharing of transactions between the front end and the back-channel. This is something OmniPay does not do - it is more concerned with the format and normalisation of the HTTP messages, and not storage or GUI.

Just as some background to that, when a notification comes in, it is direct server-to-server from the payment gateway, not involving the user and so has no context, e.g. no access to the current user's session. So it must be able to access the transaction stored in the database, so it can amend it with the notification details. Sometimes notifications can arrive a significant time after the user is involved (e.g. a cancellation of a pending payment).

[makasim]

@judgej should we use acceptNotification method instead of fetchTransaction?

[makasim]

The Payum knows the payment context (Because the notification url contains a token associated with payment in database).

[judgej]

Not all gateways support dynamic notification URLs, so the transaction ID will be in the POST data. Same thing though - there is no context until the handler inspects the incoming data.

• acceptNotification - accept a Server Request - an incoming message from the payment gateway with some updates on a transaction.
• fetchTransaction - request details for a transaction from the gateway. This is a request initiated from the merchant site, not the payment gateway.

They do two different things - assuming they are both referring to OmniPay gateway methods. So I'm not sure how one replaces the other. Unless I'm misunderstanding what you mean?

[makasim]

@judgej The payment gateway sends us a notification request, and we can fetch transaction details, update our model and act according to the changes. That's the idea behind fetchTransaction solution. Once a gateway call us we call it back.