#mark-payments
1 messages · Page 1 of 1 (latest)
Hi karbi. The subscription ID is: sub_1LSMghDvkBSqGgYf44OkXplK
I believe our test docs are inaccurate and you need to also pass in off_session: true in the update request to have this work - can you try another subscription update and pass that in?
OK - I'll give that a try.
Have done that now. Seemed different behaviour but not entirely sure what happened.
So are you still getting the same requires authentication issues with that, or no?
No, actually getting an error on the subscription update now:
Error: When `payment_behavior` is set to `pending_if_incomplete`, you can only pass supported params. `off_session` is not supported.
Ah interesting - I think this is a weird gap in our testing that the 3155 test card is meant to work with off_session , but pending updates can not be off_session. Just to try it out - what happens if you don't specify pending_if_incomplete?
What should I set payment_behaviour to?
You can set it allow_incomplete just for the sake of testing for now
ok
OK - that does seem to have worked now but presumably I'll get the problem of the subscription updating even if the payment fails now (and having to rollback somehow), which is what using pending updates avoids.
I'm a bit unclear on the current question. Are you looking in to how to detect/resolve this without pending updates or are you saying it should not be an issue as you will use pending updates?
I want to use pending updates but not have to re-authenticate the card at the subscription update stage.
Just popping in with one last thing before I head out - there is not 100% way to guarantee you'll never need to re-authenticate a card at the update stage. That's entirely up to the card issuer to decide. You're still welcome to use pending_if_incomplete, and as long as your cards are setup correctly the majority of your payments won't need to be reauthenticated, but there will still be some that need it
The 4000002500003155 card always seems to need to be reauthenticated with pending updates, which I wouldn't expect from it's description.
Yeah, that card can be tricky here from how this is always considered on session.
I'm trying to think of if there is a workaround but honestly that might only be useful in test mode. Like karbi said, these payments won't typically require re-authentication in live but there is always some chance that the issuer will request it
OK - so most cards won't behave like 4000002500003155 with pending updates? It's odd how it was OK when using payment_behavior = allow_incomplete but not with pending_if_incomplete. I guess because I can't set off_session = true with pending updates?
So will most cards not require the re-authentication even without off_session = true ?
Yes, that is the reason that the 3155 card is behaving this way. It entirely works on the logic of requesting 3DS for on session payments and not requesting it for off session payments.
And no, unfortunately you can't flag off_session for pending updates at the moment. The only way to get that logic now would be to make the update without pending_if_incomplete , send off a one-off invoice, and have your own code to roll back the update if the payment doesn't go through fast enough.
So it's either pending updates or off session payments but not both? But hopefully most cards on live won't request re-authentication with pending updates even without the off_session flag?
I guess I won't really know until we go live!
Yeah that is kind of where we are at the moment unfortunately. And the issuers probably will be more likely to request 3DS than if you were able to specify off_session but it is always up to the banks to decide so it would be hard to know how often this might happen
So that's the spirit I guess!
OK - thanks. Is off_session likely to make it into pending updates any time soon?
Not that I know of but I can definitely make a feature request for that or add to an existing one if it exists already.