#supreeth_best-practices
olive mulchBOT
👋 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/1366831313402728530
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
lime bone
Hi there!
Separating authorization and capture (the guide you linked) seems like a reasonable solution, but I'm afraid you'll run into authorization window issues - for most merchant categories, the default is 7 days. Will that be enough for you?
"Extended authorizations" where you hold an authorization for up to 30 days are regulated by the card networks to certain categories; typically car rentals and some things like that
What goes wrong in the scenario you describe? Could you describe what happens in the fraud scenario in a bit more detail?
wheat socket
hello! Sure. The problem now is users sign up with random email IDs and they use our services and when we try to invoice them for the services, their cards get declined/invalid. We use PendingSetupIntent from the subscription to take payment method details before giving out our services, but through stripe says the card is all good, the payments never go through and as a result of this, we have lost lot of revenue.
As a pre-check, is it resonable to pre-authorize a 2$ charge on the card they give us ?
And we also have rapid billing now, and they will get billed as soon as they accrue 1$ worth of services.
7 days hold should be good enough, all we want to do is weed out users/cards with no intention of paying or doesnt even have a single $ in the card
lime bone
Yeah, you could separately authorize a small fee up front separately. You could also add a one-time price to the Subscription as a "setup fee" or deposit
wheat socket
what happens if we authorize 2$ and dont capture funds ?
because we might bill them using a different paymentIntent which will come as part of an invoice.
lime bone
Nothing as far as I'm aware. This seems like something that the card networks probably don't want to see and I think the recommendation would be to use SetupIntents rather than authorizing an amount you don't intend to charge, but I understand that you're having trouble with that approach
I would point out though that there isn't anything preventing the malicious actors from cancelling their cards after the nominal fee has been paid/authorized
wheat socket
right now, we dont want to charge a fee to sign up for the service but we want to make sure the cards they give out is legit/has some funds atleast.
Yeah unfortunately setupintent is not catching the fraudsters for us 😦 and we are losing a lot of revenue because of that
Yeah I understand the risks that they can always cancel the card and payments can fail. But I am hoping our rapid billing engine should be able to catch that, and auto-suspending them.
I also want to make sure there are no other side effects of authorizing 2$ and not capturing them right ?
Its not considered a refund right ?
because when I asked last time - stripe folks said frequent refunds can flag our account.
lime bone
I wouldn't think that uncaptured authorizations would count toward frequent refunds from a risk perspective
But I couldn't say for certain; that would be a question for support, I think.
lime bone
As far as I know, yes
wheat socket
thanks @lime bone for your help!