Symphony.

Did I forget to mention that I'm not good with deadlines around the holidays? I'll be working on this over the next two weeks since the project I need it for started today. Sorry for the wait.

69% done... ya, I like that number too. Ya'll gonna like this :)

Woop! how DRY is the code? i.e would it be easy to swap stripe for GoCardless?

Woop! how DRY is the code? i.e would it be easy to swap stripe for GoCardless?

I'm someone who believes it can always be done better and that's probably an understatement with my code ;) DRY? Sure. Swap with GoCardless? Probably not. Good starting place for you? You bet. I'll be talking with Brendan over the weekend...

69% done... ya, ....'m Looking forward to

I cant decide what to sell first! that's my problem though.

I cant decide what to sell first! that's my problem though.

LOL, that's a first world problem; a good one to have :)

Yea its tough living in the first world.

I have an actual question, will the system handle subscriptions?

I have an actual question, will the system handle subscriptions?

Yes :)

Quick Update: I will be releasing a beta Monday. Those of you who are planning on using this extension I would greatly appreciate some feedback next week so that we can get it to a polished version 1.0.

It's interesting how some of my initial thoughts on implementation turned out to be not such good ideas. I've also been rethinking every step of the way to ensure it is as flexible as possible.

The Stripe API is a joy to work with but implementation of the concepts into Symphony has been a fun challenge.

Quick Update: I was testing today and came across a bug that made things unusable and spent the day working on a fix. I also came up with a better way to process webhooks that Stripe posts, making the process much more flexible than originally planned.

I'm off to bed now. I should be able to get this posted tomorrow for feedback.

https://github.com/lewiswharf/stripe

I have spent a lot of time implementing Stripe into Symphony. It may not seem like it, but it was iteration after iteration. I would greatly appreciate feedback on how I have implemented it. Negative/positive, no matter what, just please try to be constructive.

Please note this is not a final version and that it is considered experimental. With your help and my additional testing over the next week or two, this extension will be released for prime time.

No, I don't know if everything works. And yes, several things could have better logic; but this will be improved with your feedback and use cases!

Thanks!

Looks very comprehensive! A couple of minor things I noticed:

• The stripe api should probably be linked inside /lib
• The only currency supported is USD, but it looks like Stripe supports CAD too?
• No backend pages have been made to be translatable. Not a major issue as Stripe is largely North America, but there may be instances where French or Spanish translations would be useful to developers.
• It looks like the Customer Subscription and Customer ID fields are the same, can one extend from the other instead of repeating the same code?
• You mentioned in the code about if Field::* is fine. It means it will use the default Field::* implementation, instead of the parent of the current classes implementation.
• Line 86 of the Webhook Event has a typo I think, $result[$name] = $class->ROOTELEMENT; should be $result[$name] = $ext->ROOTELEMENT;

That's from a once over, I'd like to get a test Stripe account and see how it all works from a curiosity point of view (seeing as Stripe isn't available in AUS just yet)

Thanks Brendan!

The only currency supported is USD, but it looks like Stripe supports CAD too?

I'll double check on this. I know they just launched in Canada but it was either the documentation for coupons or plans that noted USD was the only supported currency at the time. They probably just forgot to update it.

It looks like the Customer Subscription and Customer ID fields are the same, can one extend from the other instead of repeating the same code?

That should've been deleted. Subscriptions turned out to be really tricky to solve until I took the approach of filters and a custom event to router a response from Stripe to the correct event with its filter. Originally I was going to have a subscriptions section set in preferences and utilize this field, but I didn't like that approach because it did not seem flexible. It would've meant setting up something similar for other webhook responses.

I believe this extension shows the true power of event filters.

You mentioned in the code about if Field::* is fine. It means it will use the default Field::* implementation, instead of the parent of the current classes implementation.

That's what I want to happen but I wasn't sure if it was bad practice. Sounds like it's not.

I'll get the rest of these things fixed today. Thanks again!

Security

Provided someone is using a XSS Filter in combination with a Stripe charge filter, how easy and common is it for someone to change the price upon checkout (submitted to the event via hidden form field, $_POST)?

I have been thinking about this a lot lately, in terms of using filters applied to events to process Stripe's API. It's the only flexible way I know to implement the API.

I'm confident that calculating prices via the database is the surest way to make sure someone is paying what they are supposed to, but that's difficult to implement as an extension that is reusable.

Does using this extension with the members extension make things more secure?

Perhaps I should include a price field that creates a fingerprint

sha1(PRICE . Symphony::Configuration()->get("secret", 'stripe')

This can be checked prior to executing a Stripe filter. However, the idea becomes complicated when you start dealing with multiple items and quantities.

I'm still debating the best way to incorporate something like this that is user-friendly.

The bigger question is… Does this type of security belong in the payment extension or a shopping cart extension?

I just had a great idea. I could create an extension:

1. Looks for a form in the markup
2. Grab the values of the hidden inputs
3. Create a fingerprint (using a secret key) from the hidden inputs
4. Append hidden input with fingerprint

Upon form submission, compare the fingerprint to the hidden input values.

Just thinking out loud :-)

@Lewis, all input from forms can be faked very easily. However, assuming you will be calculating the total somewhere, why not store that into a session and use just that?

@creativedutchmen, see my idea above you...

I almost have this fingerprint extension done and will post it up tomorrow and see what you all think.