Stripe gateway

[aseigo]

A gateway for use with the Stripe payment service.

[aseigo]

Have begun looking into this with some seriousness, finally ...

Question: would an external dependency for this be ok, in particular code-corps/stripity_stripe? It is complete, and seems to be well maintained with the 2.0 release coming along nicely.

Would make this feature a wrapper around stripity_stripe. So why would a user not just use stripity_stripe in that case? This would add a supervised process model on top of stripity_stripe; give a unified API for payment gateways that just happens to use stripity_stripe in the background in the case of Stripe; any additional gateway management / easy of use features (e.g. perhaps providing a default impl of webhooks as mentioned in issue #15).

Risks: relies on stripity_stripe to be maintained (seems safe enough at this point; and cashier could always migrate away from it if needed in future); it is currently undergoing 2.0 development, which started in / around October, so this would probably want/need to focus on that still-moving target so as not to be obsoleted immediately when 2.0 is released .. though this means relying on 2.0 actually being released in a semi-timely fashion.

What do you think, @swelham?

[swelham]

I am happy to bring in this external dependency for the gateway with my long term thought to potentially move the gateway implementations into their own packages if that starts to make sense.

I agree tracking the 2.0 release is probably the best move here as it does look to be making progress and as long as we stick with their latest publish to hex we should be able to keep the stripe gateway stable.

[aseigo]

Cool. Will work on it this, then. Thanks for the quick responses!

[swelham]

No problem at all, I am most grateful for your contributions!

[aseigo]

Quick update: making progress, but it is interesting in that Stripe now requires a browser-side bit that fetches a transaction-specific token so the customer's data never passes through your server at all. Very nice, but also a bit different in that those tokens get used instead of the actual card information. (It has indeed been a few years since I last wrote code to work with Stripe :)

Anyways, not a big deal on the server-side API (just use the token in place of the card number) .. however it does bring up an interesting question should cashier ever want to do payment routing: it would also need to direct the application which client-side UI to use! Got me to wondering if it would make sense (later) to add client-side UI components to cashier which the consuming application can use as it sees fit. This would allow cashier to make payment gateway decisions on behalf of the application without the application needing to also have conditional rendering that reflects that. Something to consider for the future perhaps ..

In any case, despite stupidly busy work weeks, have got a small client-side app for driving the Stripe gateway so that this can continue moving forward

[swelham]

How interesting, I didn't realise Stripe did that. I have seen a similar thing with the SagePay API, however this has you send the card details from the server still.

I think cashier will definitely need to have some form of UI components built in to handle this, whether we try and find a generic or gateway specific approach for this will need some investigation. I'm still not 100% sure on the current design so I'm still open to changing this to suit additional requirements.

Also to note, you will need to rebase your branch off master as the base gateway has changed a bit. There is now another use in there which builds out the consumer supervisor for the gateway, checkout the payapl gateway or give me a shout if you have any questions.