#Leviticus

1 messages · Page 1 of 1 (latest)

north patioBOT
unborn fog
#

I've used 4 cards, all of them were verified with 3D secure. But all 4 of them did not shift liability.

#

They all shift liability when setting mode=payment instead of mode=setup

#

But I of course can't do that, because I need to charge the cards in the future using the PaymentIntents API.

wispy ridge
#

I thought liability shift only occurred on charges. Are subsequent charges also not showing a shift in liability?

#

If so, can you show me where you're seeing the liability shift is not occurring?

unborn fog
#

Sorry, I'll be more clear.

So I add the card via the CheckoutSession with mode=setup, also requiring 3D Secure.

Then I attempt to charge the card using the PaymentIntents API.

I have a rule blocking cards that do not have liability_shift.

It seems that all cards being added via mode=setup cannot be charged because they are not shifting liability when the payment intent is attempted.

#

All cards that are added using CheckoutSessions with mode=setup then charged via PaymentIntents API do not shift liability.

#

I also made sure to use off_session

#

All of these cards have been verified using 3D Secure, some are frictionless as well.

#

But nonetheless, the liability will not shift.

jovial turret
#

Taking over here for @wispy ridge who needs to step away shortly

#

When you make these future payments, are you requesting 3DS? Or using off-session etc?

unborn fog
#

The checkout flow for my website is as follows.

  1. Create Checkout Session using mode=setup and off_session.
  2. Redirect Customer to Checkout Session URL so they can add their Card.
  3. Force 3D Secure on all cards.
  4. Charge the card using PaymentIntents API.

The failure is happening at step 4. I have a rule to block cards that do not have liability shift. Most cards that use 3D Secure should be shifting liability.

However, when adding a card via mode=setup and verifying 3D Secure. Then attempting to charge it via PaymentIntents API.

The card does not shift.

I've had over 100 blocked payments in the last 2 days just from this new rule in correlation to this new flow I've been using.

unborn fog
jovial turret
#

Then there is no liability shift

#

If an exemption is requested, such as the Merchant Initiated Transaction or Mail Order/Telephone Order exemptions, and it is approved by the bank, these do not shift liability from you as the merchant. The only way to obtain a liability shift is to have the customer authenticate via 3DS.

#

You only have a liability shift for the transaction when 3DS happens for that transaction (or, "could" happen)

unborn fog
#

So when charging cards automatically, for example with a custom subscription system. There will be no liability shift?

So how are disputes handled for this matter? For example, say you've been charging a card for 3 months, via a custom subscription system using the PaymentIntents API. Then on the 3rd month, the customer opens a dispute.

Also, does the Subscriptions API have liability shift? Or is there no way to have liability shift on any sort of automated card payments.

jovial turret
unborn fog
#

Can a customer make a fraud dispute on a card that was charged off_session. If that card was added using the SetupIntent API and it was 3D Secure verified?

Another variation of the question.

Does the initial 3D Secure verification for adding a card apply to the future off_session payments to prevent fraud claims?

jovial turret
#

Those have opposite answers (yes then no). My understanding is that there is no liability shift for those off session payments.

For more questions about 3ds liability though, please speak with our support team: https://support.stripe.com/contact

Stripe: Help & Support

Find help and support for Stripe. Our support center provides answers on all types of situations, including account information, charges and refunds, and subscriptions information. Get your questions answered and find international support for Stripe.