#sean_trustap
1 messages · Page 1 of 1 (latest)
the numbers work fine, but you only use the numbers to enter into e.g. an Elements form, you should never be sending them to the API directly using your secret API key.
Thanks. We still need to be able to test flows end-to-end without involving the browser though, so in this case is the recommended approach to use the tokens in this headless/automated scenario?
the suggestion is to pass strings like "pm_card_visa" when confirming a PaymentIntent
let pi = await stripe.paymentIntents.create({
amount: 1000,
currency: 'usd',
payment_method_types: ['card'],
payment_method:"pm_card_visa",
confirm:true
});
This doesn't really simulate the actual flow though, where the payment intent is created and confirmed in separate steps; can the payment method be supplied in the confirmation step instead?
let pi = await stripe.paymentIntents.create({
amount: 1000,
currency: 'usd',
payment_method_types: ['card'],
});
pi = await stripe.paymentIntents.confirm({ payment_method:"pm_card_visa"})
but overall you can not simulate the complete end-to-end flow since the end-to-end flow involves the customer entering card details in the frontend, and you can not script/test our frontend components with things like Selenium/Cypress; instead you test by mocking out the actual calls and pretending they gave you a value of a PaymentMethod object pm_xxx, and you can use pm_card_visa as the mock
Ah I see, the ability to pick up the flow in that way is new behaviour based on our experience, thanks for the information.
pick up the flow in that way is new behaviour based on our experience
no sure what you're referring to here
As in, it was previously possible to simulate the flow end-to-end using the test card numbers by using them for a payment method, setting the payment method on the payment intent, and then confirming the payment intent. This was necessary when payment intents were first published by Stripe because there wasn't any (at least advertised) way of "skipping" the payment method step (or "picking up" the flow after the payment method step) as you described above.
simulate the flow end-to-end using the test card numbers by using them for a payment method, setting the payment method on the payment intent, and then confirming the payment intent
that all still works but the idea is that you skip the "creating the PaymentMethod" part and just pass the magic string directly to the PI, that has always been possible/recommended.
In general yes, most of our integrations were/are frontend-first where you never really create or interact with the PaymentMethod yourself, you just call a function on the frontend that confirms the PaymentIntent and does everything, and the testing story has never been great.
What's different recently is we are heavily restricting the ability to send raw card numbers to the API(as you see from the error) as it's often a vector for fraud. There is a way we can opt your account for test mode but you'd have to write to support, or you can use the 'magic strings' instead of the raw numbers.
that has always been possible/recommended.
I mean, I had enquired a number of times to different levels of Stripe's support when PaymentIntents were first released about exactly this scenario and what I was trying to achieve, and told numerous times that what I was trying to achieve wasn't possible yet, so it's a little invalidating to assert that it was always possible/recommended.
yeah unfortunately the answer does depend who you get to speak to, I totally agree things are and have been really unclear
and we used to be a lot more dogmatic about requiring a 'frontend-led' approach where you never do things like confirm the PaymentIntent on the backend ever or use PaymentMethods directly in that way, and in that model it's super hard to do any testing, which is one of the reasons why our position has evolved over time and https://stripe.com/docs/payments/accept-a-payment-deferred was launched this year and we are making it more of a focus
but I totally hear you, I've been helping developers with getting this type of testing for over 5 years and it's always compelx
anyway, got to run!