#Davi_d

1 messages · Page 1 of 1 (latest)

lavish beaconBOT
rose monolith
#

Can you share the request id with me please?

spice ore
#

pi_3MmQ3dETU8N2v5f41psWlFaL

#

not sure anything changed

#

Gonna walk you through our technical integration steps just for clarity

rose monolith
#

I think there is minor type. Can you change off_session: "True", to off_session: "true", ?

spice ore
#

First, we create a default_incomplete subscription in the backend

stripe.Subscription.create(
  items=items,
  customer_id=customer_id,
  payment_settings={"save_default_payment_method": "on_subscription"}
  off_session=True
  expand=["latest_invoice.payment_intent"]
)

Then we return the payment intent's client_secret to the frontend, and confirm that intent using Stripe Elements

#

The card we're using is this one

#

Then, when a user goes to upgrade their subscription from our lowest tier to the highest one ($3.99 => $7.99), we do this on the backend

stripe.Subscription.modify(
  subscription_id,
  payment_behavior="pending_if_incomplete",
  proration_behavior="always_invoice",
  items=[{"id": old_product_item_id, **new_product_item}],
  expand=["latest_invoice.payment_intent"],
)
#

we're trying off_session = "true" - will let you know if there are still issues there

rose monolith
#

Ah, I do not think that is the issue. Let me test this card on my end.

spice ore
#

yeah when we modify the subscription as stated above, it triggers 3DS using that test card - so it doesn't complete the transaction

#

same goes for renewal (using Stripe's test clock). Renewing the $3.99 plan using the aforementioned test card also triggers 3DS and causes a failed payment

lavish beaconBOT
rose monolith
#

Still testing this on my end, thank you for your patience.

twin flame
#

thanks! happy to jump on a call too if its faster!

#

it seems that the default off_session for subscription isn't working with the test card

rose monolith
spice ore
#

this was one I manually completed 3ds in w/ a link

#

so what we ended up discovering was the following

#

we have

            payment_behavior="pending_if_incomplete"       proration_behavior="always_invoice",

in the modify call

#

and that would give us some error about "no default payment method w/ a customer" unless we did this in the create call

#

payment_settings={"save_default_payment_method": "on_subscription"},

#

but then this causes 3ds to fail when modifying/renewing subscriptions

rose monolith
#

I'm unable to reproduce this issue, for em that card is working as expected. On your modify call, you can just pass the items and nothing else

twin flame
#

stripe.Subscription.create(
items=items,
customer_id=customer_id,
payment_settings={"save_default_payment_method": "on_subscription"}
off_session=True
expand=["latest_invoice.payment_intent"]
)

#

so this is working for you? followed by

#

stripe.Subscription.modify(
subscription_id,
payment_behavior="pending_if_incomplete",
proration_behavior="always_invoice",
items=[{"id": old_product_item_id, **new_product_item}],
expand=["latest_invoice.payment_intent"],
)

#

we're suspecting its payment_settings={"save_default_payment_method": "on_subscription"}

#

doesn't work well with off session

rose monolith
#

I have payment_behavior: "default_incomplete" on my test with:

payment_settings: {
save_default_payment_method: "on_subscription"
},

#

On the modify call, I just have items: parameter to update the subscription to. (Using test clocks as well )

twin flame
#

ok, anything you see wrong with our setup?

#

why it would not set off_session correctly?

remote bronze
#

i'll take a look and get back to you in a while

#

to summarize, you're creating a subscription and collecting the payment method details using elements. Subsequently, when you update the Subscription, you're expecting it to not request for 3DS - is this correct?

#

and this is the request id for the subscription update : req_s78WNwRarODKFt?

twin flame
#

yes

remote bronze
#

can you try including off_session=true for the subscription update request?

twin flame
#

we did but it throws an error

remote bronze
#

aaah, because you're using pending_if_complete so you can't pass off_session=true

twin flame
#

yeah, do you think we need to set off_session=true

#

in the update explicitly?

remote bronze
#

hmmm, you won't be able to set off_session=true like what the error mentions since you're using pending if incomplete

twin flame
#

ok

#

if we don't have pending is incomplete

#

we think the off session would work

remote bronze
#

it would, but i don't recommend that - if the payment for the update fails, the update would still be applied

twin flame
#

yeah

#

so you think for a monthly subscription flow

#

to handle the monthly recharges

#

the best way is assume it will get re-3DS'd

remote bronze
#

also, even if you pass in off_session=true, there's still a rare possibility that the issuer would require authentication (very rare) but if that happens, the payment will fail with authentication_required

#

it really depends on the issuer, i think for the US, generally 3DS isn't as common (or required) as Europe or APAC for example

#

you should just prepare to handle that flow where 3DS is required

twin flame
#

but what flow

#

you are saying the flow where 3DS is required a month down the line?

remote bronze
#

the flow where 3DS is required for an update

twin flame
#

what about a re-charge in 3 month

#

or 1 month

#

whatever the subscription timing is

#

do we expect that to just work? and just updating be hte issue

remote bronze
twin flame
#

but in theory hte flow we have is handling it, right?

#

liek the subscripton object if created with off_session=True

#

will get re-charged automatically in a month

#

and that transaction iwll be off session?

remote bronze
#

all recurring payments with collection_method as charge_automatically are considered as off_session

#

but like i mentioned, there's the rare chance that authentication will be required by the issuer, and if you turn on that setting, Stripe will send an email to your customer to ask them to confirm the payment if 3DS is required for that recurring payment

twin flame
#

yeah totally

#

that makes sense

#

so it sounds like we setup a subscription, fi they 3DS

#

future renewals will be off session (mostly, but we'd want an email hook to cover the edge cases)

remote bronze
#

yep!

twin flame
#

nice!

#

last question

#

for testing this flow, what is the best way/way you suggest

#

doing the 3DS via the time travel UI is a bit tough because its hard to manually fill out the 3DS stuff?

remote bronze
#

for context, we don't send 3DS emails (and it's reminders) in test mode

#

what do you need to manually fill up for 3DS?

twin flame
#

i think the time travel stuff

#

you set a card

#

and by default the original payment fails because it requires 3DS (but there's no real UI, etc. to fill it out in)

remote bronze
#

are you referring to the creation of the subscription where you set off_session=true?