#cratejoy-connect-statementdescriptor

1 messages · Page 1 of 1 (latest)

storm cryptBOT
analog basin
#

cratejoy-connect-statementdescriptor

solemn mica
#

I have read it through, we are currently providing a suffix when we create the PaymentIntent itself, which when the actual charge comes through, does appear as we have specified on the customer's statement.

However that doesn't seem to be working for any authorization charges that stripe performs, we have a few customers who have written into our merchants asking why there are authorization charges with the descriptor Cratejoy on their statements, when the actual charge is CJ*Suffix as we've specified.

#

Is there an extra step I need to be doing via the Stripe API to make sure the authorization shows up with CJ*Suffix instead of Cratejoy ?

analog basin
#

which when the actual charge comes through, does appear as we have specified on the customer's statement.
what does that means? Can you be a bit more explicit/specific?
Do you mean you pass for example statement_descriptor_suffix: "SUFFIX" and on the resulting Charge you get calculated_statement_descriptor: 'PREFIX* SUFFIX'? Or something else?

solemn mica
#

when we create the PaymentIntent (via Python SDK, if that's important) we pass in statement_descriptor_suffix: "SUFFIX" on that request, and for the charge for the $amount specified, on the customer's card statement, it shows up as CJ* SUFFIX.

However, when an authorization is performed (in the examples we've gotten through support one was a $0 charge for authorization and one was a $1.10 charge for authorization if that's important) it shows up on the customer's statement as Cratejoy instead of CJ* SUFFIX

analog basin
#

I'm really sorry, this is super cryptic right now

#

A lot of our API has a really really specific vocabulary and the way you're framing your question really confuses me

#

However, when an authorization is performed
what does that mean? What authorization? In which situation? You don't set a statement descriptor for that authorization right? so why would you expect the Charge's statement descriptor there?

solemn mica
#

Whenever we capture a customer's card details, sometimes they report that it results in a temporary charge to their card, and on their card statement that charge appears as Cratejoy, which is inconsistent with how the full amount of the charge appears once it's captured, which is CJ* SUFFIX.

#

I'm just wondering if we have any control over the statement descriptor that appears for those temporary charges that are done as part of authorization somtimes, for some banks

#

so right now when a customer pays us for one of our merchant's items their bank/card statement might look like this:

$0.00 - Cratejoy
$39.99 - CJ* SUFFIX

and I'm looking for confirmation on whether or not it is possible for us to make it look like this:

$0.00 - CJ* SUFFIX
$39.99 - CJ* SUFFIX

analog basin
#

Can you share what exact API(s) you use that causes that first authorization? Because it usually means you have integrated incorrectly

solemn mica
#

Yes, we have a form on our storefronts that captures card data, and to capture that data we create a SetupIntent on the server

intent = stripe.SetupIntent.create(usage="off_session", stripe_version=STRIPE_MIN_API_VERSION)```

We pass the `client_secret` from that intent back to the javascript on our storefront and it uses that to initialize the stripe form that collects the card data.

We use this setup intent in the future when it comes time to charge the card for the purchase by creating a `PaymentMethod`

```python
token = stripe.PaymentMethod.create(
            customer=customer_id,
            payment_method=payment_method,
            stripe_account=stripe_account,
            stripe_version=STRIPE_MIN_API_VERSION,
        )```
NOTE: For new cards the `payment_method` we pass in is `None`, this is only if we've got a payment method already for the customer that we can use to capture a charge `off_session`.

We then pass that payment method in when creating our `PaymentIntent`
```python
 res = stripe.PaymentIntent.create(
        amount=charge_amount,
        currency=currency,
        payment_method=customer_token,
        customer=customer_id,
        stripe_account=None,
        metadata=metadata,
        idempotency_key=idempotency_key,
        description=description,
        application_fee_amount=None,
        capture_method="automatic" if capture else "manual",
        confirm=True,
        off_session=True,
        stripe_version=STRIPE_MIN_API_VERSION,
        statement_descriptor_suffix=statement_descriptor_suffix,
    )

We then use the id response from that to capture the charge:

pi = stripe.PaymentIntent.retrieve(intent_id, stripe_version=STRIPE_MIN_API_VERSION)
    res = pi.capture()
analog basin
#

Okay so taht's your problem really

#

SetupIntent is used to collect card details for future payments. That does save card details on your account, and that can run a $0 authorization, and there's no way to control the statement descriptor at all in that case

#

Why are you doing a SetupIntent if you immediately charge them for $39.99 afterwards?

solemn mica
#

We run a subscription service, so for customers who subscribe instead of purchase things one time we need to be able to charge them monthly for the products.

analog basin
#

Are you charging them for the Subscription immediately?

solemn mica
#

We charge them immediately and then at the end of every subscription cycle until they cancel.

#

So they might pay $39.99 monthly, we will charge them $39.99 at the time of sale and then every month after that they will be charged $39.99 to the card they used to start the subscription until they update that card or cancel

analog basin
#

Yeah so there's no reason to have a SetupIntent at all in this situation either. This is likely a misunderstanding on your end of how to integrate our products (I know you've used Stripe for years and likely slowly added bits)

#

But to summarize: when you use SetupIntent you have no control over the statement descriptor. So the behaviour you get is definitely expected
And the fix is to remove that SetupIntent entirely and move to a different flow where you confirm the first payment (whether one-time or subscription)

solemn mica
#

So what will replace the setup intent in this case? (Or if there's a specific doc that runs through it I'm happy to follow that)

analog basin
#

I mean there are dozens of docs and you have a multi-years old integration so this is going to be really complex and not a one-line change

#

If you accept a one-time payment upfront, your code should never use SetupIntents at all. You should be creating the PaymentIntent and use that to accept the first payment. You can set setup_future_usage so that the PaymentMethod gets attached to the Customer for future payments too

#

For Subscriptions it's a bit more complex, but what you can do is create the Subscription upfront with payment_behavior: 'default_incomplete'. That will give you an Invoice that will give you a PaymentIntent that you can confirm client-side, same as the one-time payment flow.

#

Both options allow you to accept a payment upfront, control the statement descriptor (though a bit more complex for Subscriptions) and save card details without using SetupIntent at all

#

You're also going to save on costs since you won't pay for 2 separate "authorizations"

solemn mica
#

Thank you! I appreciate it. The first option is what we do in our newer applications, this specifically is a very old application so definitely a lot of bolting on changes done over the years.

I'll keep that for reference in case we want to modernize it, for now the statements will have to look the way they look.

analog basin
#

sounds good!

solemn mica
#

Thanks as always!