#jason_griffing - statement descriptor

1 messages · Page 1 of 1 (latest)

thick mirage
#

Hello, good question. That is the field that I thought we populated with that info. I will look in to this and get back with what I can find

#

Can you send me the ID of the second payment?

heavy nymph
#

Yup, one sec

#

here is the charge id: py_3LGmxTFNVbYFceRM14YtSKxT

thick mirage
#

Thank you, checking in to it and will get back to you

#

Apologies for the delay, looking in to a couple other questions so it may still be a couple more minutes before I can fully look

heavy nymph
#

No worries.

#

Thanks for looking into it

thick mirage
#

Unfortunately I am not finding a way for you to look this up yourself if it isn't on these objects. For ACH it should default to the statement descriptor for the account that it is on, so you can check that if these fields are null here. But it looks like we may not populate these fields the same way as with the payment from a card

heavy nymph
#

Darn. Ok. Is there any way for someone at Stripe to look it up? The issue I'm having is that I'm getting reports from a client that ACH charges are pulling the wrong statement descriptor. However, in my testing, I'm unable to replicate the problem. And it's a huge pain to test because I'm literally having to hook up my personal checking account and issue real charges in order to see what is being output by the system.

I have 5-10 historical charges that I just want to see what was sent to the bank on. It would be an enormous help if someone was able to tell me.

Let me know if this is a better thing to take to the support team. I'm just curious if you know whether or not it's possible for someone internally to pull this historical data.

sick helm
#

@heavy nymph I'd recommend simply working with our support team here. But this is a Destination charge, you use on_behalf_of so we pull the info associated with the connected account when you confirm that payment. Did you set the right statement descriptor on that connected account?

heavy nymph
#

Yeah, the statement descriptor on the connected is definitely set correctly. The problem is we have a client telling us that his charge came through with platform account's statement descriptor.

#

So I was simply hoping that provided a charge ID, someone at Stripe could tell me what data was passed to the bank.

#

Happy to work with support. But was hoping you guys might be able to just tell me if it's even possible.

sick helm
#

so what's the issue exactly?

#

You obfuscated the statement descriptor

#

Like what did your customer see on their bank statement?

#

(calculated_statement_descriptor is only returned for card payments, so it's normal that it's null in that case)

heavy nymph
#

I'm just trying to determine what information was passed to the bank for the statement descriptor for this payment: py_3LGmxTFNVbYFceRM14YtSKxT

#

The customer claims he saw our platform account statement descriptor. But it should have been the connected account statement descriptor.

I'm unable to replicate what the customer claims he saw. And I am unable to pull historical data myself.

sick helm
#

Sure but I won't share that.

#

So I'm asking if you want to share that

#

but I can't prove who you are so I won't share private info directly

heavy nymph
#

Oh, ok. I got it. I was just looking to know if it was possible for Stripe to pull that. It sounds like it is through support.

I'll let you guys go. Thanks for the help.

sick helm
#

Yeah I looked and there's definitely something that seems strange here and we don't seem to set the right descriptor from what I can tell

#

talking to support is your best course of action

heavy nymph
#

I've been going back and forth with them for weeks. Friendly and helpful, but no one I talk to seems to be able to give me a straight answer

#

I'll keep chipping away

#

I am curious to know if there is anything at all you can tell me about you're seeing. No worries if not

sick helm
#

Okay here's what you can try: Move to PaymentMethods.
Basically this is a legacy bank account object from our old ACHv1 integration. If you change that Customer to have invoice_settings[default_payment_method] set to that ba_123 and it will use the newer integration path and should fix it

#

you should be able to test it, though annoying to have to really debit your bank account

#

Not sure it will work but it'd be a quick test worth doing

#

but really talking to our support team is the best path forward

heavy nymph
#

Oh cool. Thanks for that tip. I will definitely give that a shot and will keep pushing forward with the support team.

Thanks again for the assist.