This is an exciting project for drupal because stripe the stripe service will allow for a drupal site builder to accept payments with an easier road to achieving PCI compliance. However, because the stripe service is so different, we're going to have to implement some fairly interesting workarounds to make sure that it's done properly.

I suggest the stripe.module be a central module that contains apis, logic, configuration, and helpers, that can be utilized by all drupal sites, but doesn't really do anything by itself. Actual functionality can come in the form of secondary modules packaged with this project and will allow for "turn it on" integration as much as possible. Of course the apis and helpers of the main module could be used by other modules/custom integration as needed.

Thougts?

Comments

Brackish Lake’s picture

Brackish Lake commented

Hi,

I couldn't agree with you more. I can tell you in our 6.x branch (which is very early on and should not be used anywhere near a production environment (https://github.com/brackishlake/stripe) is being designed in just that way. But there is also a concern to watch out for. First the good news.

1. We are working really hard on the 6.x branch. We have an incentive to iterate quickly: many of our customers who want it fast and a need for it in our own project management tool (though that's written in node, not Drupal).
2. We are building the module to serve solely as a core foundation and set of API tools. (I know our fork isn't yet in sync with that goal. For example, if there are traditional cart functions, we absolutely plan to move those outside.)
3. In our own implementation for http://shinyneedle.com, we're doing just what you said: using the 6.x fork as a helper module. But the initial calls to set payment amounts are written elsewhere in that client's Drupal site.

Now the bad news — which is solvable.

One thing that is important for PCI compliance and unique about Stripe - it keeps card data from being POSTed. It does this by zeroing out the name attributes of the form elements. But given how drupal_get_form() and drupal_prepare_form() work - that alone won't cut it. The submit handler still receives the form values.

I'm juggling both the 6.x branch of stripe for Drupal — but we're also contributing to a stripe module for node.js. Maybe it's the mash of PHP and JS swimming through my head - but I'm not sure of the best way to handle that PCI issue.

I instinctively want to use drupal_get_form to serve up the checkout page, but maybe it needs to be bypassed. Again, it's possibly I'm missing something obvious.

vordude’s picture

vordude commented

Awesome! let's take the PCI/form discussion over to #1301024: Figure out how to handle form data (Which I probably posted while you were writing this)

sirkitree’s picture

sirkitree commented

Small change to this I think might be:
1. #1301024: Figure out how to handle form data
2. We build integration for Ubercart, Commerce and Pay as separate projects. One shouldn't have to obtain the code for a different module's integration of stripe in order to get the one they want. Projects should be created like commerce_stripe which would hold Commerce's transaction hooks that utilize Stripe.

liorkesos’s picture

liorkesos commented

I'm totally in for the ride.
Will be a tester and possibly be able to contribute some code.
Regardrding the above +1 on the commerce integration.

minnur’s picture

minnur commented

Depending on the free time I can help with integration with Ubercart.

vordude’s picture

vordude commented
Status: Needs review » Closed (fixed)