#kabala_api

1 messages · Page 1 of 1 (latest)

mint ruinBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1410039065310531604

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

shut spear
#

hmm, I'm not sure if that's supported. What does BBVA stand for? Do you have an example failure request or PaymentIntent id?

modern pelican
#

BBVA is the name of the card issuer

#

It is a very large card issuer in Mexico. We are seeing a high number of payment declines because of bad CVV.

#

I was wondering though, is the CVV saved in the payment method in Stripe? I had assumed it was only used for the initial registration and would be discarded one the PM is linked to the Customer record

#

Your card's security code is invalid.
Transaction ID: ch_3Ryb5oJbsD3XvV0X0P0gQlII

Your card's security code is invalid.
Transaction ID: ch_3Ryb6VJbsD3XvV0X1Rapg68s

#

pi_3Ryb5oJbsD3XvV0X0mpuilyR

#

pi_3Ryb6VJbsD3XvV0X1AMjqQm6

shut spear
#

CVV cannot be stored long term

#

looking at the examples

#

okay, so is this an off-session charge where the cardholder isn't present in the checkout flow?

#

probably the reason why you're getting cvc related declines is because you're passing the paramter setup_future_usage: "off_session" while also creating/confirming a PaymentIntent in a single API call

modern pelican
#

The cardholder is present, let me double check that parameter

shut spear
#

Ah, I see, you're creating Payment Methods directly with raw card info

modern pelican
#

That's correct

shut spear
#

Is this a one-time charge, or do you expect to charge this customer's payment method again in the future?

modern pelican
#

We expect to charge again, after one month another donation as part of a subscription

#

Use off_session if your customer may or may not be present in your checkout flow.

This seems correct. Present for first payment and not present for subsequent

shut spear
#

Yes, on subsequent charges you would omit setup_future_usage and pass off_session: true

#

But, from what I gather so far, there are known issues with BBVA cards and cvc declines. That said, declines issues are not our focus in this server

modern pelican
#

I believe the issue is more due to the CVV being used more than once. Can you tell if the CVV is passed when the PM is registered and in the PI?

shut spear
#

CVC isn't present in the call to create/confirm a PaymentIntent - you're using a Payment Method token (pm_) and CVC isn't stored on the Payment Method

modern pelican
#

Where does the CVV code come from then?

#

If CVV is not passed in the payment intent the decline reason makes no sense

mint ruinBOT
shut spear
#

Correct, but sometimes issuers respond with decline codes that don't make much sense.

I think in this flow the cvc check would take place on the call to attach the PaymentMethod to the Customer, but in these instances it looks like that check was not run. Understand that Stripe provides the card details to the issuer here (cvc, postal code, expiry) and the issuer makes the decision on what to check/not check.

here is an example:
https://dashboard.stripe.com/logs/req_uCEKGqLheFeM9E

modern pelican
#

I understand but if CVC is not provided in the payment the decline reason should be something different. My understanding is that there is no specific decline code issuers send but they will indicate the CVV match result. In the payment intent it should be absent or "unchecked"

#

For these example payment intents can you tell what the issuer responded?

spare mason
#

Hi there, taking over here and gimme a while to catchup

#

Correct?

modern pelican
#

Yes

spare mason
#

Okie so let me explain again. Stripe stores the cvc after you created the PAN Payment Method in a very short period, but because you subsequently created a PaymentIntent in right after, we used that CVC on the PaymentIntent creation (and this is good / expected)

#

Sorry for the confusion, we did use the CVC on the 3rd step, creating the PI

modern pelican
#

I see. Is there a way to avoid using the CVC in that third step?

spare mason
#

I am not sure about the BBVA issuer. Normally passing CVC will increase auth rate. But you are facing decline (maybe) because of BBVA card nature

#

Saying maybe because we wouldn't know why BBVA declined it. In the end it's their decision

modern pelican
#

The decline is because the CVV changes for second use. I would prefer not to omit CVV

#

This issuer has one time use CVV codes

#

If we introduce a delay between payment method creation and payment intent will the CVV be discarded before the payment intent?

#

And how long a delay should that be?

spare mason
#

There were 2 timing CVC was being used, I think it's 2nd step (attach) and 3rd step (first PI). Confirming that.

But to avoid this, you shouldn't introduce the timing cause the timing is something undocumented and can change in the future. I believe you should change the integration instead

#

Yes it was used twice. I found 2 records on our system. This confirms why it fails on the 3rd step since this is dynamic CVC

#

Okie how about this

#
  1. You created a raw PAN Payment Method
  2. You create and confirm a SetupIntent using the collected Payment Method. (This will mark it for future usage, and also trigger a card validation to consume the CVC)
  3. You create the sub-sequent PaymentIntent, but with off_session=true and no setup_future_usage
#

This way, your step 3 won't send the CVC. Step 2 already marked it as future usage

modern pelican
#

The other option I was considering would be to swap the payment intent for a subscription, would that trigger a CVV validation?

spare mason
#

Sub will trigger a PaymentIntent under the hood, and if you don't pass off_session=true, it will attempt to use the CVV (which is already consumed on the attach step)

modern pelican
#

In your proposed flow, does the setup intent attach the pm to the customer? We're doing that as a separate action now

spare mason
#

Yes it will, equivalent to the Attach step you did

#

The different between SetupIntent vs a pure attach is, SetupIntent also marks the future usage to this PM, allow next step can use off_session