#zepatrik_api
steep plumeBOT
👋 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/1226826869287157802
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
barren heartBOT
tulip shuttle
hi! well you have to confirm a PaymentIntent/SetupIntent on the frontend really to properly get a mandate.
You also should be using default_if_incomplete for subscription creation.
Overall I would say, use default_if_incomplete , then confirm the subscription->latest_invoice-payment_intent with your SEPA test information. For the purposes of a test you can do that on the backend and pass mandate acceptance. (in reality you would do this using Elements and confirmPayment on the frontend).
https://docs.stripe.com/api/payment_intents/confirm#confirm_payment_intent-mandate_data
https://docs.stripe.com/api/payment_intents/confirm#confirm_payment_intent-payment_method_data-sepa_debit
rich cargo
we're using checkout for "real" customers, so that works fine
I just need to find a way to test async payments on webhooks, but there are literally zero docs on how to do that
I think I now understand that I need to work with the "low-level" setup-intent to create a mandate, thanks
tulip shuttle
I think it's much easier/closer to reality to confirm the PaymentIntent from the Subscription's Invoice than to do a separate SetupIntent first but either works yes
rich cargo
yes that's what I meant, creating the subscription with should then have a pending_setup_intent which I then modify to get the invoice paid
docs are really lacking on that...
tulip shuttle
well there wouldn't be a pending_setup_intent since there's a payment required here, hence latest_invoice->payment_intent.
pending_setup_intent is only for when you create a Subscription and e.g. there's a trial period or coupon that means no initial payment is needed, but you can use the SI to accept + save a payment method for the future payments
rich cargo
hm ok, we're always using the high-level invoices and subscriptions, so this is quite confusing
tulip shuttle
ultimatley I think you should just do the tests manually using Checkout in your browser to generate the webhook events, since at this point you're basically building two entirely different integrations
rich cargo
no way, we need automated tests for everything
tulip shuttle
as in you use Checkout for the actual real code on your site, but you've also integrated Subscriptions directly just for the tests
as you wish then!
rich cargo
all I need is some real "checkout.session.async_payment_succeeded" and "checkout.session.async_payment_failed" events
but the cli only provides fake data that don't make sense
tulip shuttle
the easiest way then is to use Checkout in reality(in test mode).
and then you can I suppose save the events JSON and use them as fixtures/mocks for future tests
rich cargo
we already do that with playwright tests, but I'm not sure we can then use test clocks to see the events
the issue with fixtures is that we have some internal datastructures as well that have to match, so the right internal ID has to be in the checkout sessions metadata for example
tulip shuttle
yeah there's not really a good solution here really, we don't support automatic/backend testing of Checkout in this way
rich cargo
I also looked at the APIs checkout is using, but I guess they could change unexpectedly
tulip shuttle
we already do that with playwright tests, but I'm not sure we can then use test ...
AFAIK no, test clocks are only for specific features of Billing
I tink you can use the test numbers from https://docs.stripe.com/payments/sepa-debit/accept-a-payment?web-or-mobile=web&payments-ui-type=stripe-hosted#test-integration in Checkout and it will generate the appropriate async_* events
rich cargo
I mean I am using the test numbers from there, it's just hard to get it to work actually
tulip shuttle
hard in what way?
rich cargo
so this is the code we use for card payment testing
which I am now trying to recreate with SEPA, or any async method
and I just could not get the subscription to be correctly created with the sepa method
tulip shuttle
that code makes no sense to me, you create a Subscription object and then try to pass it to a non-existent subscription paramter on CheckoutSession creation.
like to clarify the options here are
a) use Checkout normally in test mode using the payment methods you're interested in, do testing by manually visiting the Checkout page in your browser and entering the test numbers, that generates objects and events and such and you can use that in your test
b) build an entirely separate direct-Subscription-API-based integration(a version of https://stripe.com/docs/billing/subscriptions/build-subscriptions?ui=elements but backend-only, using stuff like I posted at the start of the thread to confirm a PI on the backend) just to generate evens that look sort of like what you expect(but not really, since it will not generate any checkout.session.* events for instance and Checkout won't be involved at all
I wish there was an option c) do automated tests with Checkout, but there is not.
rich cargo
I mean that does not surprise me with the rest of the testing experience.... e.g. we have 4 stripe accounts just so we have enough testing accounts for all our environments
and also that we have to reverse-engineer stuff like the signature header to send our own test events (even snapshots because the current time is part of it)
stoic smelt