#taylor-brooks-simple_api
delicate glacierBOT
👋 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/1306323384489218150
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
visual rock
Hello! To clarify, you asked about a tokenization request, but then you provided a request to attach a Token to a Customer. Those are two different things. We do not perform validation beyond the basics (length, luhn check, etc.) when tokenizing, but we do perform validation when attaching a Token to a Customer. That validation often, but not always, triggers a $0/$1 authorization with the card network.
storm loom
Yeah you're right, those requests aren't the same.
That request 402'd, a request two days later (req_r8j5vB9z7O1pJ7) succeeded.
I don't believe anything changed on our side, so I'm trying to figure out what was different and why one request succeeded and the other failed.
visual rock
That's the same failed request.
storm loom
Sorry, req_kXiIjH8lnFhyND
visual rock
You attempted to attach a different Token which may contain different information.
visual rock
It's not really possible to see for sure. They might have made a typo the first time.
storm loom
Lemme see if I can re-test and provide two new req_ids...
visual rock
You should not test in live mode. It's against our terms of service and can result in undesirable results.
storm loom
Sure, i can't replicate the error in test mode.
visual rock
Can you tell me what your ultimate goal is? These types of errors/declines are normal and to be expected.
visual rock
You would need to reach out to the card issuer in that case and ask them why this was declined.
storm loom
The root cause is that we are getting these errors for all Canadian cards issued by RBC (Royal Bank of Canada).
Our merchant (who also played cardholder) called RBC and their response was:
"on the first transaction we see a merchant name of simple donation. It is a 0.00 authorization request that behaves like a registration / save request for a visa number. This is declined, because it has SimpleDonation.com as the vendor."
On the request to attach a token to a customer, is there a way to control the auth amount?
visual rock
No.
storm loom
Do I have the ability to use $1.0 instead of $0?
visual rock
No.
storm loom
Do I have the ability to send over a different merchant name?
(the connected account name instead of the platform)?
visual rock
Yes, you can change the statement descriptor in your Stripe account settings.
Wait, connected account?
There's no connected account involved here.
delicate glacierBOT
storm loom
Where do I set the statement descriptor in this request?
visual rock
You can't.
Can you tell me more about what your setup is and what you're trying to accomplish?
How are connected accounts involved, for example?
It sounds like you might want to switch to Setup Intents and set on_behalf_of to the connected account, but it's hard to say since you've provided very few details.
storm loom
When we go to make a charge request, we pass the on_behalf_of param
We don't use PI, we use the /charges endpoint
visual rock
Yeah, okay, that's going to be a problem then.
storm loom
Why?
visual rock
Because I don't think there's any way to work around this on a legacy Charges integration. Let me have another look, though...
Yeah, I can't find anything. If you're directly attaching card information to Customers on your platform account your platform's statement descriptor will be used for any authorization that takes place. The only two workarounds would be to either switch from your legacy integration to a modern one which uses Setup Intents + on_behalf_of or switch from destination to direct charges, so the Customers, Tokens, etc. exist on your connected accounts instead of on your platform and would thus use the connected account's statement descriptors.
storm loom
That's a big shift
visual rock
Yep, both are very significant changes to make.
storm loom
We have 842k cardholders with payment data on the platform account.
Instead of using the attach function on the sources endpoint, would it be any different using payment_methods?
visual rock
Do you reuse the same Customer/payment info on your platform across multiple connected accounts?
storm loom
^ Yes.
visual rock
Okay, then switching to direct charges isn't going to work.
Using our modern APIs you wouldn't directly attach. Instead you'd use a Setup Intent to set up the payment info for future use. You can do that while also setting on_behalf_of so the merchant of record and setup is performed for a specific connected account. That would solve the statement descriptor issue, but it also doesn't seem appropriate for your use case either since you should be setting these up/attaching them at the platform level since you're using them across multiple connected accounts, not just one specific one.
The idea is that the attach/setup authorization should be performed by the entity that's going to be reusing the payment info later, which is your platform, not one specific connected account, right?
visual rock
To put it another way, if you get the statement descriptor set to a specific connected account... say "Account A" for example... that might work for that initial attach and the first payment, but then later a payment using that same info for "Account B" might be declined because it's unexpected.
storm loom
Yeah.
A customer can have multiple payment methods with the same fingerprint correct?
visual rock
Yes.
Since you're having issues with a specific card issuer you might want to engage more with them to determine what the best course of action is. The answer might be to switch to dymanic suffixes instead, for example: https://docs.stripe.com/get-started/account/statement-descriptors#static
Really we can only guess what the card issuer is going to do, you'd need to talk to them to be sure.
storm loom
Yeah I've been working directly with RBC.
Their response was, "send an auth for $1 (instead of $0) or do not pass 'simple donation' across on the auth request"
visual rock
The first approach isn't viable. The second approach is unclear... did they say waht to pass instead of that?
storm loom
Based on what you're saying I don't have any control on the auth amount, but using SetupIntents I do have control on the statement descriptor"
They want the merchant name
Which in this case is "Alliance Canada"
visual rock
But that's a specific connected account, right? That's not the same connected account you'll always use in the future with this card?
That just happens to be the first one?
storm loom
Honestly I'm just throwing shit at the wall to see what sticks. I'm not convinced a string change in teh statement descriptor will make the auth go through.
storm loom
That just happens to be the first one?
This is actually a really good callout. I don't have data handy on how many cardholders use their card across multiple accounts. If I had to guess, it's a very small minority.
visual rock
It's possible they see a bunch of $0 authorizations with SIMPLEDONATION.COM but never any payments, so they started blocking the $0/SIMPLEDONATION.COM combo. If that's the case (and I'm just guessing here!) using the connected account's statement descriptor might work fine.
storm loom
Yeah, that's an interesting hypothesis.
visual rock
Do you ever do any non-zero payments with the SIMPLEDONATION.COM descriptor?
storm loom
No.
visual rock
Yeah, that kind of thing often looks fishy to card issuers.
storm loom
After attaching a card to a customer, there is always a charge request immediately following
storm loom
Yeah, that kind of thing often looks fishy to card issuers.
Interesting, I wonder if switching to SetupIntents we would see a lift in auths
visual rock
If I were you I'd switch to Payment Intents, set setup_future_usage and on_behalf_of, and that way you won't have any $0 authorizations at all.
If you're immediately taking payment there's no need for a Setup Intent. Setup Intents are only for when you're not taking a payment immediately but are saving payment information.
If you create a Payment Intent with setup_future_usage it will perform the same setup as a Setup Intent and handle attaching the payment info to the Customer for you.
storm loom
Is the Payment Intent created when the page loads?
visual rock
Are all of your connected accounts and platform in the same country?
You can do it either way, you can create the Payment Intent when the page loads or you can have it created later in the flow.
Here's how to do it later in the flow, for example: https://docs.stripe.com/payments/accept-a-payment-deferred
storm loom
No, platform account is US. Majority of connected accounts are US, some CA, some AU, some NZ.
visual rock
Okay, you probably want to perform the setup on behalf of the connected accounts anyway, to make sure the payment info is set up for use in that context. If you perform setup on your platform only, and it's in the US, you're not going to set it up properly for things like 3D Secure where that's required.
Your current integration doesn't support 3D Secure at all, so that's another reason to make the swtich.
storm loom
When you say, "perform the setup on behalf of the connected accounts" what do you mean?
visual rock
When you create a Payment Intent with setup_future_usage you would also set on_behalf_of and specify the connected account. That would peform the setup and payment with the connected account as the merchant of record.
That means the card issuers will see, for example, an NZ customer transacting with an NZ merchant instead of an NZ customer transacting with a US merchant.
Does that make sense?
storm loom
Yeah, that makes sense.
Can you pass a token to a PaymentIntent? (sorry I know this is probably in the API docs -- I can't find it)
brittle tide
👋 stepping in as Rubeus needs to step away
Yes, you can pass a Card/Source/Token to the payment_method parameter for PaymentIntents -- it is backward compatible.
storm loom
Is there a way I can export this convo? I want to make sure we start getting things in the dev queue for migrating to PaymenIntents.
brittle tide
You can save the link -- it will become read-only but won't be deleted.
storm loom
Awesome.