Nyxi

[surreal wraith]

I thouht it was the country of the user, but apparently it's the Stripe account's country

[velvet tide]

👋 happy to help

[delicate forum]

Hi!
Yes, that's the Stripe account's country. However, when you initialise the Payment Request, you haven't provided Stripe.js with clientSecret yet, but it already needs the country information to display the Apple/Google Pay pop-up.

Similarly, you might think you have all the information about the purchase in the PaymentIntent, but you still need to type in the amount and the currency when creating a Payment Request. Unfortunately, it's a limitation of how Payment Request works.

[surreal wraith]

Alright, cool. I just wanted to make sure.

[delicate forum]

Of course. Please, let me know if you have more questions.

[surreal wraith]

I do, actually. Unrelated. If a payment intent is in requires_capture, and I want to move it back to requires_payment_method but without canceling it, how would I do that?

[delicate forum]

You can just change the Payment Method

[surreal wraith]

Can I do it without having a payment method?

[delicate forum]

Why would you need it to get to that state?

[surreal wraith]

Because I have a webhook-based flow where the state of the payment intent becomes important. requires_capture means "we are waiting for the webhook to land", so on failure, I would want the webhook to reset the payment intent but not cancel it

And the reason I'm talking about "failure" is because it's a ticketing system, so the webhook must ensure the tickets are still available before it can cmplete the capture

[pulsar merlin]

Hi there 👋 jumping in for my teammate as they need to step away soon. You will need to take an action on the Payment Intent that causes the state change, you cannot just change the state. I believe most updates on an intent in that state will move it from requires_capture to either requires_confirmation or requires_payment_method depending on the change.

Thinking through your business use case, if the tickets are not available then what are you hoping to reuse the Payment Intent for?

[surreal wraith]

Yeah I suppose I could just recreate the payment intent if the user wants to try again

I was thinking to just "update the payment itnent with the updated info", but cancel and recreate is also fine

[pulsar merlin]

What is the updated information that you have? Does updating the Payment Intent with those details result in the behavior you're looking for?

[surreal wraith]

New ticket reservation attempt would potentially have a new price

But it's fine, I can cancel it

If a payment intent is in requires_capture and I call cancel() on it, there is no realistic scenario where that would fail (bar server error)?

[pulsar merlin]

Correct

[surreal wraith]

Okay, thanks

[pulsar merlin]

Any time!

[surreal wraith]

    /**
     * @param PaymentIntent $intent
     *
     * @return void
     * @throws ApiErrorException
     */
    private function handleCancelPaymentIntent(PaymentIntent $intent): void
    {

        try {

            $intent->cancel();

        } catch (ApiErrorException $exception) {

            if ($exception->getError()?->payment_intent?->status !== PaymentIntent::STATUS_CANCELED) {
                throw $exception;
            }

        }
    }

So this is a pretty fail-safe way to cancel it, including if multiple sources try at the same time

Or does the API silently do this for you? Assume cancel on already canceled == success ?

[pulsar merlin]

That seems fine, but I'm not sure I understand the questions raised in your last message.

[surreal wraith]

I mean if it's just considered a success if you call cancel on an already-canceled intent

Like, if I don't need the above check at all

[pulsar merlin]

Oh, gotcha. No, the API will return an error if the intent has already been cancelled.

[surreal wraith]

Alright, cool

If I call capture on a payment intent that is not in requires_capture, I will get payment_intent_unexpected_state, yes?

[pulsar merlin]

No Sorry, read too fast, yes.

[surreal wraith]

Great

[surreal wraith]

And canceled is also the only state that will trigger payment_intent_unexpected_state if cancel() is called on a payment intent?

As in, the only un-cancelable state

aside from succeeded

of course

[pulsar merlin]

processing also typically blocks cancellation

[surreal wraith]

but for card payments, processing is essentially the same as succeeded, is it not?

This async stuff with tickets is race-condition hell

[pulsar merlin]

Yes, card payments know immediately whether they succeed or fail.

[surreal wraith]

ok