Payment Method Fails [#2235321]

Hey Maciej,

So I installed Commerce Stripe, set "Send payments to" (here: /admin/commerce/marketplace/payment) to "main store," enabled the payment method a store, and then attempted to buy an item from that store. I get the following error:

    Notice: Undefined index: stripeToken in commerce_stripe_submit_form_submit() (line 211 of sites/all/modules/commerce_stripe/commerce_stripe.module).
    We received the following error processing your card. Please enter your information again or try a different card.
    You must supply either a card or a customer id
    Notice: Undefined property: Stripe_InvalidRequestError::$json_body in commerce_stripe_submit_form_submit() (line 275 of sites/all/modules/commerce_stripe/commerce_stripe.module).

I turn off marketplace:
drush dis commerce_marketplace, commerce_marketplace_cart, commerce_marketplace_customer, commerce_marketplace_line_item, commerce_marketplace_order, commerce_marketplace_payment, commerce_marketplace_product, commerce_store, commerce_store_ui

Now I can buy the item without errors.

I was under the impression that setting the payment recipient to "main store" would result in playing nice with payment modules. Is that the idea? I'm going to see what's going wrong here and report back to this thread. Let me know if you've got any ideas about what could be going on.

Comments

Comment #1

glass.dimly CreditAttribution: glass.dimly commented 7 April 2014 at 23:26

Well, it's getting all the right parameters over to the Commerce Stripe module... except for $params['card']. Which is null, and shouldn't be. I'm parsing through all hooks and alters to figure out what's happening. More later.

Comment #2

glass.dimly CreditAttribution: glass.dimly commented 8 April 2014 at 15:36

Problem is that Commerce Stripe is trying to be all clever with javascript just like Commerce Marketplace. Disabling the submit button. Creating a credit card token with JS. Stuff like that. More later.

Comment #3

glass.dimly CreditAttribution: glass.dimly commented 8 April 2014 at 19:45

Status:

Active

» Needs review

So I got this worked out.

Commerce Stripe was traversing the payments form dom using id's and classes formed like "commerce-payment," whereas our form has various classes like "commerce-marketplace-payment."

I've added a js setting to Drupal.settings to tell whether commerce_marketplace_payment is enabled here, I think this is a good way to allow other modules to change the way they're navigating the dom. If multiple modules had to add the module_exists() to the module settings, it would be duplicate code. So I think we add the setting in Commerce Marketplace.

If that's cool, let's close this bug, and I'll submit a patch based on that setting to Commerce Stripe and follow up on this thread.

The other option for us is to make the form id conform to the expectations of other modules and change 'commerce-marketplace-payment' to 'commerce-payment.' It would make it more likely that other modules would work out of the box with Commerce Marketplace.

-jj

Comment #4

maciej.zgadzaj CreditAttribution: maciej.zgadzaj commented 9 April 2014 at 15:14

Status:

Needs review

» Needs work

Thanks for investigating this.

No, adding that extra Drupal.settings is not really the way to go, at least not if it could be solved in a different way. If there already is one module traversing DOM and checking for ids/classes, there might be more, and we can't expect them all to account for such edge cases, looking for specific modules being enabled or not. At least as long as it is possible.

Changing this to 'needs work', to see if the same classes could be used by commerce_marketplace_payment as native commerce_payment uses (this could be a temporary solution, assuming of course that it would really solve the issue in question). My guess would be that it should be doable with classes, not so much with ids.

Therefore, in terms of real solution, first thing to consider is whether there really is a need for separate marketplace-specific checkout panes, or would it be possible to use original DC panes, just change their behavior as needed.

And as I am already planning to look into some checkout pane issues, I might look into this at the same time as well.

Comment #5

glass.dimly CreditAttribution: glass.dimly commented 11 April 2014 at 18:40

There're a few more related issues here, in that form id's had an appended "--1," rendering like "commerce-checkout-form-review--1" and "edit-continue--1."

I think this is likely as a result of generating multiple forms for checkout, something which can't be gotten around.

So even if we do use DC default form ids we'll still be breaking some DOM traversal, as from a DOM-traversing module builder's perspective it would be logical to use the form id "commerce-checkout-form-review." But that can't really be helped.

I'll look at traversing the classes, that would likely be doable since the JS is only loaded on the correct pages.

Something to think about.