thephpleague / omnipay

A framework agnostic, multi-gateway payment processing library for PHP 5.6+
http://omnipay.thephpleague.com/
MIT License
5.92k stars 929 forks source link

Confused as to how exactly you use this? #592

Open marbuser opened 4 years ago

marbuser commented 4 years ago

So I've been trying a fair bit now to get this to work, and I'm struggling due to how little information there is both on the main package as well as a lot of the drivers?

I was hoping to see some examples especially with webhooks because I'm confused as to how you are supposed to accept them. Would be nice to see some full flow examples for both SSR and via something like a Rest API. Would also be neat to see how to implement this into Laravel correctly.

I really didn't want to put a message here since this should be reserved for bugs, but honestly the fact a package this large doesn't have a somewhat basic collection of documentation and integration examples makes it really hard to even make PoC's with it, let alone implement it into a full blow web environment.

judgej commented 4 years ago

This simple app provides an example of the drivers in action:

https://github.com/thephpleague/omnipay-example

It gives you screens to enter config data, and to enter payment data, and they will run through the steps to perform the required action. It may be worth exploring that.

Webhooks are generally not a core function of Omnipay. Some drivers have some support for them., but it largely depends on how necessary those webhooks are for processing payments (for some gateways, the webhooks are vital). They will be documented separately for each driver.

Now, the overall lack of documentation is really down to how this all works. Someone needs a driver, creates it, publishes it, then they have other tasks to deal with that don't involve documentation. That's not an excuse, just a reason, and it's unfortunate but that's where we are. If you spot anything missing that you an spend ten minutes just creating a PR for, then please do, they are always very much appreciated. Some of us are able to help you with specific drivers and issues you may be having. All I personally ask for, is that what has been learned is put into the documetation (by PR) for the next person to start at a higher level.

Getting Omnipay into Laravel - try Barry's package to help pull it all together with unified config, service, provider etc:

https://github.com/barryvdh/laravel-omnipay

Is there any one overriding concept or idea in Omnipay that you just don't feel you get? What is the most important single thing missing for you?

marbuser commented 4 years ago

@judgej

Thanks for the incredibly informative reply! I had taken a look at the example shown previously, and I managed to understand most of it, but applying it into my project is a bit of a challenge since my backend is working as an API rather than SSR.

Regarding the documentation side of things. Of course, I agree that for the drivers that doesn't come down to the fault of the people working on the core OmniPay package. However, even for the core package the documentation is a bit lacking.

When it comes to the webhook stuff, I feel that webhooks are sort of a vital part of just payment flows in general, since the alternatives all seem pretty fragile or worse than webhooks. Not to mention that since I'm working in an API capacity and not an SSR capacity, it's quite hard for me to use the non-webhook confirmation and since it's synchronous I'd have to log it into the DB and then have some cronjob check it every x amount of time, a webhook just seems more suitable. The problem I'm having as well is that drivers for providers that RELY on webhooks don't seem to have the functionality to do it.

For example, I can sort of hack together some basic undocumented webhook functionality with the Mollie driver, but when it comes to the webhook response I have to do it all manually and can't use anything like; $notification = $gateway->acceptNotification();

I also found that on the Stripe driver, I'm not even sure if it's able to be used anymore due to SCA. All the methods on there are Charges or Payment Intents, and afaik they are both not compliant with SCA. I think under some circumstances Payment Intents could be compliant, but then the issue I'm having is coming from colliding documentation.

The Stripe docs state you should;

  1. Create a Payment Intent on the server and return the key to the client.
  2. Use Stripe.JS with the key to allow the user to pay.
  3. Process the payment.

But then on the Stripe Driver for Omnipay it says;

  1. Collect card information from Stripe.JS and create token.
  2. Submit token to server, create payment intent, charge user.

And I'm not really sure what one to follow. Obviously I want to try follow the Stripe one since it's their API, but the problem I then have is I don't even think I can create a Payment Intent via OmniPay without a token.

As for the Laravel Omnipay thing, I wasn't sure that package was still relevant since it's for Laravel 5 and not 6, and hasn't really been worked on in a while so I wasn't sure if it was still usable.

The main thing I'm struggling to understand is the flow of payment with OmniPay when it comes to webhooks. For example, I want to use webhooks for both Stripe, Mollie, and possibly PayPal. How would I go about doing this and are there any good examples that are available for me to see (preferably laravel), where I can see just how the flow works and also the structure of the code like controllers and such.

Thanks and Regards

judgej commented 4 years ago

Laravel 6 support was added a few weeks ago. I'm not sure anything really changed in it:

https://github.com/barryvdh/laravel-omnipay/blob/master/composer.json#L13

marbuser commented 4 years ago

@judgej

When I try to require it with composer, it gives me an error; image

Do you have any suggestions of how I should tackle the problems I listed? Thanks!

judgej commented 4 years ago

Webhook handling is a complicated one, since there are so many different responses expected from different gateways. Some just expect a 200, some need a JSON message, and some need response bodies with more archaic formats. All these could be rolled up into a PSR-7 Response message for total consistency, but Omnipay is a little older than that, so it will take some time before that happens.

Omnipay is concerned with the comms between the application and the gateway only, so handling the backend flow is really down to you. You will need to store the payment attempts, and join them up with the webhooks. I've not seen a generic wrapper to do this yet (would love to see this done), but I know some applications such as Ameos do this internally. So you will probably need to understand a little more about the gateway flows than should ideally be necessary.

For Stripe and Mollie, the developers for those drivers (not me) would be best ask.

judgej commented 4 years ago

Hmm, no release tag for Laravel 6 yet - give @barryvdh a nudge or try dev-master to get going.

barryvdh commented 4 years ago

I tagged it, but you don't really need that package to be honest.

I do agree that webhooks aren't always that clear. Usually you can just call completePurchase() to finish it and return 200 response, but some need something specific.

marbuser commented 4 years ago

@judgej Thanks that seemed to work!

@barryvdh Thanks for that. I did actually want to use this package anyway though since the convenience of the facade and such are pretty awesome.

After I've played around with OmniPay a bit more, I'll see in the next few weeks if I can perhaps start recording some newer documentation. :)