#jason_griffing - ACH DD
hushed goblet
Take your time.
I've been researching a lot to try and figure it out, but I'm stuck 🙂
brave dock
Okay so since your subscriptions are set up with on_behalf_of that indicates you are using Destination charges.
The Subscriptions exist on the Platform account, not the Connect Account
hushed goblet
Interesting. Give me a second to type this up because I have a question....
hushed goblet
When I look at this documentation on creating destination charges—https://stripe.com/docs/connect/destination-charges#create-a-charge — "To create a destination charge, specify the ID of the connected account that should receive the funds as the value of the transfer_data[destination] parameter:" (Screenshot 1)
When I retrieve a recent ACH charge in Postman, I can see that the transfer group is set to 'null'
This is what lead me to think that we weren't doing destination charges.
But if I'm understanding you correctly, the use of on_behalf_of implies that we're using destination charges?
brave dock
If you could send me a recent charge ID I can review this for you
hushed goblet
py_3LGmxTFNVbYFceRM14YtSKxT
brave dock
Okay got back to the subscription creation request for this payment
https://dashboard.stripe.com/logs/req_9DSuZAMAorlEIu
This is really weird. There's no transfer_group, there's no Account header, no destination charge at all
hushed goblet
So I am fairly new to Stripe and was not involved in setting any of this up at the outset. What I do know is that today, for whatever reason, we're set up in such a way that all of the money from these charges comes to us and then actually use a manual reconciliation process that lives outside of Stripe to pay our connected accounts their share. I'm gathering it's a pretty unorthodox setup and I'm not sure why it was set up this way. Also not sure if this tells you anything useful.
I understand your comment about the lack of a transfer group being weird. But can you elaborate at all on the Account header? What does the presence of that (or lack thereof in this case) indicate to you?
brave dock
Okay so now this is starting to sound like a Separate Charge & Transfer scenario.
Let's review this funds flow: https://stripe.com/docs/connect/charges-transfers
hushed goblet
I've read this page in detail and believe that's what it this is as well, but here's where I get tripped up. If you go back to my original inquiry, it indicates that ACH charges using separate charges & transfers with on_behalf_of should pull the statement descriptor from the connected account. But that isn't happening.
brave dock
If there is no defined value for the Connect Account it will fall back to the Platform statement descriptor
Can you check the status of the Connect Account's statement descriptor and prefix values?
brave dock
Yup...so the bank wants a descriptor so we send the platform's info
hushed goblet
Also worth noting that we have dozens of subscriptions for this same connected account that pull the statement descriptor correctly when a credit card is used
hushed goblet
Yup...so the bank wants a descriptor so we send the platform's info
Sorry, what do you mean? The statement descriptor is set. Maybe you're referring to the fact that the prefix is null?
brave dock
Yes
Because the Connect Account is not supplying any data we fall back to the Platform's information
hushed goblet
But would this be consistent with the fact that charges on this same account for different subscriptions where the client uses a credit card (and not ACH) work fine?
brave dock
How do you mean "work fine"? What is the difference?
brave dock
I'm sorry I don't have the time to watch a video. There's too much activity. here
hushed goblet
Ok. It's only one minute long, but the audio didn't capture anyways.
All I'm trying to say is that we have dozens of subscriptions for this same connected account where the charge statement descriptor works fine today, even with the prefix set to null.
The only charges that are giving us problems are those where the customer is using ACH.
It sounds like the place for me to go dig is on the prefix. Happy to do that. I just wanted a sanity check: does it make sense to you that that would only cause problems for ACH charges and not for CC charges?
If it would cause problems for both, then the hypothesis is very likely wrong
brave dock
I barely have 10 seconds to spare per thread.
hushed goblet
Ok, I understand
No worries. I can let you go. Just wanted a gut check. The null prefix being null is not causing problems on CC charges. But I can try setting it to something for ACH and see if it helps anything.
I appreciate your help.
brave dock
No I'm circling back and checking in. I just don't have much uninterrupted time. I'm still looking
Can you share IDs for the payment that does have a valid descriptor and one that doesn't for the same customer?
hushed goblet
Not exactly, because they're for different customers. They are two different customers of the same connected account.
Here's the payment ID where the statement descriptor worked as expected: pi_3LNIatFNVbYFceRM1p46rQxK
Here's the payment ID where the stateement descriptor rolled back to the platform: pi_3LGmxTFNVbYFceRM1Jq8Yl3j
brave dock
Okay and that account does have a statement descriptor set.
hushed goblet
Yeah, confusing right?
brave dock
🤔
hushed goblet
There's just something different about how the ACH charges are being processed and I can't figure out what is happening. It seems complicated by the fact that these are charges that are being automatically generated by a recurring price point. They're not one time charges that we're firing from our code base where I could just go modify the call we're making.
So here's something that might hold a clue: https://stripe.com/docs/payments/ach-debit#statement-descriptors
Every ACH Direct Debit payment shows up on customers’ bank statements with the name of the merchant. For payments created with Stripe, the name of the merchant is your Stripe account’s statement descriptor. You can override this default behavior for every transaction independently by using a dynamic statement descriptor. To do so, specify the statement_descriptor parameter when creating the PaymentIntent.
brave dock
I know ACH handles statement descriptor somewhat differently
hushed goblet
But my question is: How would I go about modifying the paymentintent to inject this custom statement descriptor? Meaning, the paymentintents are being automatically generated by Stripe. So I'd have to somehow "intercept" the paymentIntent after it's created but before the charge is run to inject my custom statement descriptor?
brave dock
You would listen for the invoice.created event, then update the invoice with the statement descriptor you wish to use
hushed goblet
Ok. So it sounds like there's a window of time between when the invoice is created (and thereby the paymentintent) and the time when the charge is actually issued. I think I saw somewhere that this is "about an hour"?
brave dock
Yup, 1 hour in draft to account for any last minute changes
hushed goblet
Ok, I'll go do some testing with this model. I really appreciate you sticking with me on this one. You guys are all amazing here in this server.
brave dock
We try to offer more help than confusion 😅
hushed goblet
You guys do great. Lol. Take care.
BTW - do these threads get archived if I need to reference back to it should I figure out some way to export it?
hushed goblet
ok, got it. I'll just save the link. Take care.