Bit - setup_for_future_usage

[viral eagle]

hello

[nova vine]

Hello. One moment

[viral eagle]

ok

[nova vine]

Why would you want to unset it exactly? Am a bit confused on that

[viral eagle]

easy... I have a service which can be sold either "one shot" or with a recurring subscription. The product is the same, just different selling plan.... so, the customer clicks on "subscription", I create a PaymentIntent with "setup_future_usage" to "off_session", then he changes his mind and clicks on "one shot".

I can't unset it, I have to throw away the PaymentIntent and create a new one

while if he does the opposite, I can reuse the same PaymentIntent because I'm changing from "null" to "off_session"

so I'm asking myself... why I can set it on one direction and not on the other ?

you should implement a "no_save" state, or something similar

[nova vine]

Hello. If you set setup_for_future_usage to an empty string it should unset it

Can you try that?

[viral eagle]

yes, I already tried it, this is the API response:

You passed an empty string for 'setup_future_usage'. We assume empty values are an attempt to unset a parameter; however 'setup_future_usage' cannot be unset. You should remove 'setup_future_usage' from your request or supply a non-empty value.

[nova vine]

Can you share the request ID there?

[viral eagle]

let me search it

req_HEcxURriZ6Q67q

[nova vine]

That's because you tried to unset it on creation

You can update it with an empty string

But on creation, either pass on_session or off_session or don't pass that parameter at all

[viral eagle]

oh I see, I'll try then, thank you.

I have some other questions about some other issues, should I ask it here or on the general chat and what for a thread to be opened ?

[nova vine]

You can ask here

[viral eagle]

I see a lot of failed calls in the API logs. One I can't understand is, for example this type here: req_LInlUU9xff31d9

I don't understand what's the real scenario happening that raises it

[weak hare]

👋 I'm just hopping in since @nova vine has to leave soon - give me a minute to catch up

[viral eagle]

ok 🙂 you just need to read two lines above

[weak hare]

I think what's happening here is for that Payment Intent, the 3DS flow was started but never finished and so it's stuck on an earlier attempt (blocking you from cancelling the more recent attempts).

Is this something you're seeing happen often?

[viral eagle]

I have it on an average of 10% of total Payment Intents on a daily basis

Some even repeated several times for the same PI, like req_2loHKmYKFaglKu, req_zGxCFAPr3JvSRv, req_VG9fxhlj8326xX, req_uWSgUhx7uMRxRn, req_Kp9354mdTQuhfV, req_ySJsOJ8kiSmpTy, req_9nglPAgwmtHa1S, req_EqfoNnTOnV2prL,req_QKvaaV9eT75zmk

all belonging to the same PI

(pi_3KWJrzDdn72I1qqY4rAuyw5E)

wth... how many times this customer tried to pay !?!!!

!!!!! 123 !???????????

[weak hare]

Yeah, that's really quite a lot - let me also do some more digging to see if there's anything else I can find out

[viral eagle]

thank you very much

[weak hare]

👋 We've dug into some of these failing requests so I want to leave some context here:

• We don't think these failing /source_cancel should affect the customer's ability to actually complete the payment. The 3DS authentication is failing before the failing source cancellation request is happening.
• This is an error you can see if you try and have 3DS flows going at the same time for the same payment intent (like having it open in two different tabs). I don't think this is what's happenign with the specific example you gave, but just want to give that context
• Overall, I think these requests are safe to ignore but we'll look into them a little more to see if something is wrong on our end

[viral eagle]

ok, thank you for the feedback so far