#zepher2211_webhooks

1 messages ¡ Page 1 of 1 (latest)

primal kestrelBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can 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/1247652664112840764

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

odd berry
#

Hi there!

still shadow
#

Hi

odd berry
#

I don't quite follow this:

succeed in creating a charge, but the charge will subsequently fail

#

You could try the card ending in 0341 or pm_card_chargeCustomerFail; you'll be able to attach this card to a custmoer and any subsequent charge using this card will fail

still shadow
#

Basically I'd like this code to succeed:

        const charge = await stripe.charges.create({
            amount: amount,
            currency: 'usd',
            source: parameters.cardToken,
            description: `Example,
            metadata: metadata as any,
        });

But to later get a charge.failed event in a webhook, I'm not sure if that can happen with a card payment but I want to handle for it if so

#

I have tried that card number but it immediately comes back

#

And just so you can know I'm doing my due diligence I'd already been using that table

odd berry
#

Gotcha, that can't happen with a card payment

#

Cards are synchronous payment method types so charge attempts will either succeed or fail immediately

#

Slight tangent: can you share why you're integrating with the Charges API?

still shadow
#

Oh okay, if that's not possible then there's no worries

odd berry
still shadow
#

We use payment intents for some purposes, within my org though I'm not the one to ask as to why we use charges for some purposes and payment intents for others.

#

It might be that the backend code powering this is legacy code and we don't want to rebuild it using the new API, at least for now, our new functionality has recently used payment intents

odd berry
#

Ah, I see

still shadow
#

Imagine building a modern front end for old functionality, if that helps

odd berry
#

That was mostly out of curiosity for me. There's currently no deadline for moving over to the PaymentIntents API