Support confirmation of SetupIntents with a payment method ID

[bpcreech]

Previously localstripe only supported confirmation of SetupIntents with payment_method_data, which is a dictionary containing the information needed to create a PaymentMethod. The Stripe SetupIntents API also allows the caller to pass in an already-created PaymentMethod, by ID. This change adds that capability to localstripe.

I also added a few of the canonical test articles you can use as a payment method ID. These generally map 1:1 with the test card numbers.

[feliixx]

Hi @bpcreech, thanks for this useful addition !

I've run our internal test suite against this change and everything looks good 👍 We'll merge and release the change once the PR gets a second approval from one of my colleagues.

[H--o-l]

Nice, thanks @bpcreech!

I wonder why you removed:

            if obj.payment_method is not None:
                raise UserError(400, 'Bad request')

And also why you added:

        self.payment_method_types = [pm.type]

I imagine that you have a good reason, and for us, it works as before, so I'm OK with it. But next time, don't hesitate to highlight every changes that are not obvious, either inside the commit message or by posting on the corresponding lines inside the opened PR, like that you will avoid questions from us.

PS: nice work 😎

[bpcreech]

@H--o-l good points! I added those in initial testing but now I see they're not quite right. We did need to change the input validation (you must specify a payment_method XOR payment_method_data when you call confirm) but there's still a case where we should throw 400.

I created #229 to do that... and to remove the spurious override of payment_method_types which you spotted.

[bpcreech]

Actually @H--o-l I tested this with the real Stripe API, and the change happens to have been correct.

The old behavior: If you pass a payment_method or payment_method_data during SetupIntent creation, and then try and pass in another payment_method_data during confirmation, you get an error 400.

The new behavior: If you pass a payment_method or payment_method_data during SetupIntent creation, and then try and pass in another payment_method_data during confirmation, the new payment_method or payment_method_data overrides the old.

The new behavior is correct. To try this with the real Stripe API:

HOST=https://api.stripe.com
SK=sk_test_...
curl -sSfg -u $SK: $HOST/v1/setup_intents -X POST -d payment_method=pm_card_visa
seti=.... # copy and paste the setup intent ID from the above
curl -sSfg -u $SK: "$HOST/v1/setup_intents/$seti/confirm" -d return_url=https://bogus -d payment_method=pm_card_chargeCustomerFail
# note it works! Stripe uses the new payment method.

There is no documentation of this behavior on Stripe's site https://docs.stripe.com/api/setup_intents/confirm. However, conveniently, just removing the special logic adheres closer to the undocumented behavior, so I think we can keep it this way.

[H--o-l]

@bpcreech thanks for the double-check and the explanation, works for me 👍