#appchargeguy
lean marsh
pulsar python
calculated_statement_descriptor is something that's only for cards - it's meant to show you what it looks like when you combine static + dynamic portions of the descriptor
for non-card payments we don't set it because you set it directly as statement_descriptor
lilac pond
for cards, where statement_descriptor is sent in the payment intent, without statement_descriptor_suffix, than the calculated_statement_descriptor is set to the 'statement_descriptor' value of the 'payment_intent_data'
since the suffix (dynamic descriptor) is not set in the 'payment_intent_data' than the shorten descriptor is not used for the 'calculated_statement_descriptor'
however, the doc says the following: "For non-card charges, if you set a value only for statement_descriptor on a payment intent, Stripe uses it in place of the account statement descriptor (static descriptor)."
https://stripe.com/docs/payments/account/statement-descriptors#dynamic
so, why is that although I set the 'statement_descriptor', and only this in the 'payment_intent_data', for non-card payments, the calculated_statement_descriptor is NULL
pulsar python
calculated_statement_descriptor being null for non-card charges is just expected behavior. For non-card charges what we send over is statement_descriptor (https://stripe.com/docs/api/payment_intents/object#payment_intent_object-statement_descriptor)
non-card payments have no dynamic components at all, so there's no need for us to calculate anything
lilac pond
I understand.. thanks, but I also see that 'statement_descriptor' is null...
pulsar python
Can you share an example Payment Intent ID showing that?
lilac pond
yes, just a moment, not sure yet if I identified the problem...
hi Karbi, i've had just re-checked again, I see that the statement_descriptor is set correctly as you said, (I thought that the calculated_statement_descriptor should not be null for all case but taken from the relevant fields each time...)
thanks a lot!
pulsar python
👍 awesome! glad I could help