#george_payment-element-testing

1 messages ¡ Page 1 of 1 (latest)

winged schoonerBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1227586237259321367

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

mystic locustBOT
rustic tinsel
#

hi! the short answer is no, we don't support that really. The idea is sort of that in a test you wouldn't mount/use Stripe at all, you'd skip to the logic for a successful payment or so on.

winged schoonerBOT
sullen falcon
#

Hello. Thanks for the response. Is this documented somewhere?

patent abyss
#

Frontend interfaces, like Stripe Checkout or the Payment Element, have security measures in place that prevent automated testing, and Stripe APIs are rate limited. However, you can simulate the output of our interfaces and API requests using mock data to test your application behavior and its ability to handle errors.

winged schoonerBOT
#

george_payment-element-testing

sullen falcon
#

I've seen this guide but there are no examples on how to test Payment Element on client side. It only references stripe-js functions and not UI elements (i.e. using React)

patent abyss
#

Because you can't test Payment Element as the paragraph above states. You'd test the functions that ultimately succeed/fail/error

#

In your test suite you need to just remove the Payment Element from the equation, and simulate calls to confirmPayment using a pm_xxx test token that gives you the behaviour you want to test

sullen falcon
#

I see.

#

Are you aware of any examples maybe besides the document you shared? The way I see this we need to mock the Payment Element (so it won't render and trigger the networks calls to Stripe) and also simulate the function calls for the setupIntent/paymentIntent

patent abyss
#

No examples because it won't work and you shouldn't depend on it ever working (we may change the internal markup in the iframe and break your test suite, for example)

#

Then you can use the pm_xxx tokens from here to simulate success/errors/declines etc in your test suite

Use test cards to validate your Stripe integration without moving real money. Test a variety of international scenarios, including successful and declined payments, card errors, disputes, and bank authentication. You can also test non-card payment methods and redirects.

#

Completely obfuscates the need for mounting a Payment Element instance which you can't fill with test card details anyway

#

You can actually use confirmPayment too if you accept non-card PMs (just don't think it's documented):

confirmPayment({
  clientSecret: 'pi_xxx',
  confirmParams: {
    return_url,
    payment_method: 'pm_xxx'
  }
})
sullen falcon
#

Thank you for the links. Those are useful for manual testing during development. They would also be useful if we decide to actually communicate with Stripe API
But in our case we are talking about simulating those functions on our tests (essentially, mocking stripe-js)

patent abyss
#

Then stub the function responses as you need. I'm not sure I understand what you're asking me really

sullen falcon
#

I was trying to state that we don't want to interact with the network layer and prefer to mock/stub

patent abyss
#

Then sure, you can do that as you need. But we don't have any libraries or tools to help with that

mystic locustBOT