#_code

1 messages · Page 1 of 1 (latest)

obsidian stormBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can 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/1247233536503713815

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

icy tartan
elder osprey
#

I can't look at the dashboard as its managed by a partner firm and we don't have any access. i dont think i can get access any time soon

#

will this be a issue? :/

#

They gave me this feedback and that's im going off of:

I've investigated with stripe and their feedback is that you have to make sure you’re collecting zip codes in your checkout. This rule will block charges if the card issuer can’t validate the zip code provided with what they have on file for the card. At this moment there is no option to see the zip code for the customer, the only way would be using Stripe tax: https://docs.stripe.com/tax/customer-locations This requires your customer’s location to automatically calculate tax.

#

also worth mentioning we do not collect the zip code from the use when the credit card details are collected as we have ths information about the user already (they are KYC-ed)

#

so we just pass this info into the sdk's function

icy tartan
#

Unfortunately this will be very hard to debug without access to the API requests. The first step I would take for you would be to log the exact payload just before the API call is made in the SDK.

elder osprey
#

the call is made by the SDK. i could try to inspect the network request. is there an example that i can compare it to?

#

on our side, the error looks to be "generic card decline" btw, not sure if that is of note as well

icy tartan
#

Yeah no you need to be looking upsteam of when the SDK makes the request

#

But just upstream

#

So assign the parameters to a single variable and log that variable immediately before calling the SDK method with the data

obsidian stormBOT
elder osprey
#

this is the payload right before its passed to "confirmPayment" from '@stripe/stripe-react-native'

{
"paymentMethodType": "Card",
"paymentMethodData": {
"paymentMethodId": "pm_1Ov1xFHcInZCHmyGh3ZHf8wX",
"billingDetails": {
"name": " John Doe",
"email": "test@test.com",
"address": {
"city": "Iphofen",
"country": "DE",
"line1": "Am Stadtgraben West",
"postalCode": "97346"
}
}
}
}

#

this is on the test environment, i dont have an easy access to test on production right now, but on production people also have all of the address info filled out as it is a requirement to use our app

icy tartan
#

If your requests are successful in Test mode but fail in Production, that is where you need to add the logging to be sure you are making the requests you expect.

elder osprey
#

so the object looks fine and you suspect the data is malformed in production?

icy tartan
#

This request succeeds in Test mode, right?

elder osprey
#

it does, yeah

icy tartan
#

Then the first step I would take is to verify that this is the same data you are passing in production

elder osprey
#

i suppose if there is nothing obviously wrong with the object thats the best step, yeah 👍

icy tartan
#

I hope it's an easy fix!