#KRS-Subscription

1 messages · Page 1 of 1 (latest)

glacial knot
#

Hi there, what kind of scrambled text? and can you share with me the PaymentIntent ID?

opal needle
#

this is the PaymentIntent ID for the 2nd month payment - pi_3LEdUDI5vSu94Gk80AGGTbZL

#

it is non readable characters is what has been raised as issue from the customer. we don't have the snapshot of what it is exactly.

glacial knot
#

I don't see a problem in the statement descriptor that's set on your account

#

Can you ask your customer to provide a statement snapshot? so that we can see what was printed on the statement.

opal needle
#

We don't have direct access to the customer and it is via a service provider. I will try to get snapshot, but sure how successful (US based customer, so it will take a day or two to get it). Is there any other way to confirm it?

glacial knot
#

I believe only your customer can access their bank statement.

opal needle
#

What we are observing is that in the stripe's 2nd invoice the statement_descriptor is null. Could this cause an issue?

glacial knot
#

The statement_descriptor is used in non-card charges.

opal needle
#

statement_descriptor is for non card charges - does this mean we cannot use it for recurring payments with card?

#

setup a static Statement Descriptor in Stripe Dashboard - What should be fix here? we remove the static descriptor and allow it to be set it via product?

glacial knot
opal needle
#

Thanks, I will read through. Do we know what is the value that has been sent from stripe to the bank for this invoice?

glacial knot
#

Since this payemenIntent pi_3LEdUDI5vSu94Gk80AGGTbZL doesn't have a statement_descriptor_suffix, Stripe will send the static Statement Descriptor to bank.

opal needle
#

Ok. If we want to remove the static descriptor including the prefix and want it to be dynamic for each product how do we acheive it?

glacial knot
opal needle
#

I can see the statement_descriptor_suffix is available only for the the PaymentIntent object, but for recurring charges we dont create PaymentIntent. How do we update it?

#

yes, the document says that Prefx * suffix, where prefix is static

#

we don't want static, in that case can we remove the static prefix from the dashboard and use only statement_descriptor_suffix ?

glacial knot
opal needle
#

Ok. Will add the implementation to update PaymentIntent. How do suggest we update the existing invoices? is there any recommended way to update it or list all the upcoming invoices for all customers and ensure the suffix is added the the PaymentIntent object?

glacial knot
opal needle
#

it says that recurring invoices created in draft state and moved to open after 1 hour, so we have window of 1 hour to update the the suffix. but what should we do for the existing open invoices? Can we update the suffix in the PaymentIntent object OR not possible? any other way to add suffix?

glacial knot
#

It depends on the PaymentIntent status, if the PaymentIntent is already succeeded, you can't change the suffix anymore. But if the PaymentIntent status is still one of the following statuses: requires_payment_method, requires_confirmation, requires_capture., you can update its suffix.

opal needle
#

ok. thanks.

#

one more thing. we don't want any static prefix, it has to be always dynmic based on the product. so if we keep the prefix as empty in the dashboard and update only suffix (with max of 22 characters), will it work? or Prefix is mandatory to append the suffix?

glacial knot
#

I don't have an answer for it. All the users that I 've worked with would like to have their brand name displayed in the static statement descriptor.

opal needle
#

Since we are an aggregator for multiple providers, our brand is not known to the end user, only the provider's information will be meaningful to the end user.

glacial knot
#

Just did a quick test in my Dashboard, you can't delete the Statement descriptor

#

Are you using Stripe Connect?

opal needle
#

Yes, each provider will have a connect account.

glacial knot
#

Are they Standard or Express accounts?

opal needle
#

Custom accounts

glacial knot
#

OK, then if you are using destination charge with on_behalf_of , the connected account will be displayed in the bank statement,

opal needle
#

no. we are using connect only for the transfers. so the end user's subscription or invoice is not associated with connect account. once we receive the payment to our company stripe account, then we use connect account for transfers.

glacial knot
opal needle
#

It does not work for our use case, as there is a possibility of more than 1 transfers for a single payment to different connect accounts. our process is once we get the payment, based on the product configuration we create transfers for 1 or multiple connect accounts.

glacial knot
#

With OBO param, the end customer will see the connect account displayed in the bank statement instead of platform. I believe this is a better solution than updating the statement descriptor suffix.

opal needle
#

so the OBO param will be used for bank statement description with connect account information (country and delay days does not affect us now). I will take it to the team for further discussion on whether we can use OBO param. thanks.

#

for the short term, is it possible to check if prefix is mandatory in order to append suffix?

glacial knot
#

I did a quick test in my dashboard, and I can't delete the statement descriptor, it requires at least 5 characters.

opal needle
#

yeah, but you mentioned that if suffix is present then prefix* suffix will be used right?

glacial knot
#

Yes. sorry I should be more clear, you can't delete the statement descriptor prefix in dashboard.

opal needle
#

I did delete the prefix (Which was earlier set to SUB). are we reffering to the same field Shortended descriptor?

glacial knot
#

Ah, I was referring to the Statement Descriptor

opal needle
#

so if the suffix is present in the paymentintent, the shortetnded descriptor will be used instead of the statement descriptor.

#

this is what i understood. correct me if i am wrong.

glacial knot
#

OK, so when suffix is present in the paymentintent, shortetnded descriptor will be used as prefix if it's available, otherwise the statement descriptor will be used as prefix

opal needle
#

Ok. understood.

#

Is there any way that we can test this? the correct statement descriptor is reflecting the bank statement, we do have test accounts for development. OR any other mechanism to verify it?

glacial knot
#

I'm afraid that there's no way we can test the bank statement.

opal needle
#

one more clarfication on the same. as explained earlier, only the 2nd payment's bank statement is showing different text, but the 1st payment is showing the correct descriptor which is configured on the product. how do i explain this behavior?

glacial knot
#

Let's ask the customer to present the bank statement so that we can verify the issue.

opal needle
#

ok.