#Jasperste-descriptors

1 messages · Page 1 of 1 (latest)

tiny hound
#

Hello 👋
Let's chat here

hazy ledge
#

Thanks. We are struggling a lot with setting the bank statement correctly for Stripe Connect Standard payments. But after a second thought it seems like we can go with paymentIntent.statementDescriptor since when using that for connected Standard account payments it will consistenly always be visible on the bank account of customers, both for card as for non-card payments. This does mean however it ignores any configures connect account statement descriptors.

Could you confirm this is most common or at least logical in our case?

void robin
hazy ledge
#

Yes, multiple times.

#

Hence the original thread as well.

#

Set the statement_descriptor and statement_descriptor_prefix for flexibility in setting statement descriptors on charges.

void robin
#

So as a platform you can't just pass statement_descriptor, if you do it won't do what you want, it'll just append to their default descriptor.

hazy ledge
#

Is currently the only mention about it there

void robin
#

If you use Direct Charges + Standard accounts, then it's on each account to set a clear statement descriptor in their account settings and that's what we will use

hazy ledge
#

It's not actually. If we set statementDescriptor on a session's paymentIntent it will use that, and ignore any statement descriptor in the account settings

#

At least, that's what we found when doing so, while expecting the account descriptor somewhere it didn't show up anywhere when using descriptor on paymentIntent.

#

For example. An account has the descriptor configured via the dashboard with 'Bakkery XYZ' (we can't set this via the API with Standard accounts). We initiate checkout sessions for the bakery with a statement descriptor referencing the order id, via paymentIntent.statementDescriptor. This leads to only having the order id reference on the eventual bank account, ignoring the account descriptor

void robin
#

https://stripe.com/docs/upgrades#2019-02-19

The full statement descriptor for a card payment may no longer be provided at charge creation. Dynamic descriptors provided at charge time will now be prefixed by the descriptor prefix set in the dashboard or via the new settings[card_payments][statement_descriptor_prefix] parameter in the Accounts API.
You likely are on an older API version

hazy ledge
#

We do not use 'on_behalf_of' currently. We use Standard Accounts. Could that be the problem?

#

I think we are on the latest version, I will check now

void robin
#

on_behalf_of is irrelevant for the quote I put above

#

Do you have an example PaymentIntent id I can look at? pi_123

hazy ledge
#

We are on 2022-08-01 btw

#

Yes, I have.

#

pi_3Ln14fR3LSvDToux0l6G2exS

#

This is not a card payment. However we do see it for card payments as well. For example pi_3Ln13WR3LSvDToux1clyL9au

void robin
#

ah it's not a card payment that's why

#

Okay let's look at the card one: what do you think the statement descriptor is?

hazy ledge
#

I actually have a screenshot of the result for the card one

#

It shows the paymentIntent statement descriptor as you can see. Same as the Ideal one, but also for Apple Pay it will only show the paymentIntent statement descriptor. We havent seen the account descriptor anywhere so far

#

Which lead us to think (hence above question for confirmation) that at least the paymentIntent statement descriptor works consistently for our situation

void robin
#

I'm sorry I don't really follow most of your last sentences

#

as far as I can tell the statement descriptor in the API is what is in your screenshot

hazy ledge
#

Sorry about that. I can try to rephrase.

#

There a basically 2 statement descriptors. One on the account and one on the paymentIntent when creating a session. At first we expected both to be visible (combined or such) on the bank statement. However it turns out it always picks the one from the paymentIntent

#

We saw the combination can be done when using card payments. Using a suffix by setting that on the paymentIntent. it will then combine the account statement descriptor with that suffix. However we also have non-card payment methods.

#

We then found that if we set the paymentIntent statement descriptor it always uses that one, for both card and non-card payments. That does mean however that anything configured by a connected account gets ignored (except if we add it manually ourselves)

void robin
#

Gotcha.

hazy ledge
#

Since the paymentIntent statement descriptor works consistently (it always shows on the bank statement) it seems like that's our only option to have something logical on the bank statement. That's why I was wondering if you / anyone would confirm that, or if we are overlooking something

void robin
hazy ledge
#

All right, I will do that.

#

Thanks anyway for trying to help out.

void robin
#

Sure, sorry I couldn't help more but I'd be worried to give you wrong information right now