#ryancwalsh

1 messages · Page 1 of 1 (latest)

golden moatBOT
rancid parcel
#

Hello 👋
The docs you shared above for error codes is a comprehensive list, you can use that to show the specific error messages to your customers. There isn't a separate list

glass imp
#

https://stripe.com/docs/error-codes#expired-card says "The card has expired. Check the expiration date or use a different card." but the actual message that Stripe returns (as I showed in the log above) says 'Your card has expired.'

They are not the same.

How/where can I see the list of those messages (what Stripe actually returns)? Thanks.

rancid parcel
glass imp
#

Thanks, but I'd already found that page too, and it still doesn't help.

See how it says expired_card The card has expired. The customer needs to use another card.

It does not match 'Your card has expired.'.

rancid parcel
#

I mean it really means the same thing.
The API won't return any different error codes than what you're seeing on the page. The language might have some variation but it should get the point across.

glass imp
#

I know that it's going to be conceptually on-point, but on principle, since my company is responsible for our users' experience, we always want to know the exact words that we're displaying.

Obviously, given the lists we've looked at above, I could manually write a whole bunch of switch statements to handle every single possible error code.

It doesn't seem like Stripe would want to create this extra work for every developer.

What I was hoping to do instead is look at wherever your list of messages is defined, and I could decide either that they all look good enough or I could write a limited if statement to overwrite -some of them as necessary (and let most of them flow through to the user unchanged).

Is there some way you could find that list of actual messages? I'd appreciate it!

(And I wonder if that's what Stripe meant to publish in these docs.)

rancid parcel
#

asked a colleague, will respond as soon as we have something

glass imp
#

I just got another Stripe question from my boss, actually.

We're a music teaching platform. Students find a teacher and pre-pay for a lesson.

Currently, we're using paymentIntents.create() and passing Stripe.PaymentIntentCreateParams.TransferData so that the relevant teacher (who has a Connect account) will receive the appropriate cut of the amount.

But sometimes students cancel the lesson far enough in advance that we'd want to offer a refund.

It seems like our options might include:

  1. Refund the student, and manually go pull money out of the teacher's Connect account (is this even possible?)...or...
  2. Change our flow so that the initial paymentIntents.create() does not pass Stripe.PaymentIntentCreateParams.TransferData . Then later, once the teacher confirms that the student attended the lesson, create a transfer of the appropriate amount to the teacher. In this case, is it possible to somehow link the transfer to the original paymentIntent so that the records in our Stripe dashboard are clear? I don't see a paymentIntent ID argument in https://stripe.com/docs/api/transfers/create

Thanks.

rancid parcel
#

So it looks like we don't guarantee that the error messages will never change in the future. We typically recommend developers to rely on the error_code instead. The error message list is just for reference as to what the error message could look like. The list I shared earlier was at one point consistent with the error messages returned by the API but looks like it has diverged recently. I'll flag internally to make sure that gets updated.

glass imp
#

Ok, sounds good. Thanks for your help.

#

For # 2, if we decide to go with that approach for some reason, is it possible to somehow link the transfer to the original paymentIntent so that the records in our Stripe dashboard are clear?

#

E.g. In our current flow, from https://dashboard.stripe.com/payments/pi_3O1bcwCUgLv5AZVY1CulXUdW you can click into the transfer and then from their into the "destination" teacher account. That sometimes feels really convenient.

If we change our flow to do the transfer later, I wonder if there is a way to preserve that functionality of linking the payment to the destination account of the teacher.

rancid parcel
glass imp
#

Ok, so it sounds like the nice feature of easily being able to click links in the dashboard (from payment to transfer to destination account) wouldn't be possible, and instead we'd need to read the arbitrary metadata that we'd attached and go visit URLs manually.

rancid parcel
#

When you say dashboard, do you mean Stripe dashboard?

#

Stripe dashboard should show the linked transfer afaik, not sure though. We don't know anything about dashboard flows

golden moatBOT
glass imp
ruby fiber
#

Glad that part is working well. Apologies but the server has been busy and I have not been able to fully catch up to this thread. Do you have outstanding questions about this flow at the moment?

glass imp
#

My remaining question is:

We are considering changing our flow so that the initial paymentIntents.create() does not pass Stripe.PaymentIntentCreateParams.TransferData . Then later, once the teacher (who has the destination Connect account) confirms that the student attended the lesson, we'd create a transfer of the appropriate amount to the teacher.

In this case, is it possible to somehow link the transfer to the original paymentIntent so that the records in our Stripe dashboard are clear? I don't see a paymentIntent ID argument in https://stripe.com/docs/api/transfers/create

hanzo said we could pass metadata, but I'm guessing that since it's arbitrary metadata, we'll lose the functionality that we've been enjoying about being able to trace a payment to a destination Connect account merely by clicking links in the Stripe dashboard.

Instead it sounds like we'd need to read the arbitrary metadata that we'd attached and go visit URLs manually. Thanks.

ruby fiber
#

Destination charge is like a more automated SC&T flow so things otherwise may mostly be able to stay the same for your integration

glass imp
#

I'll look at that page more closely, but my first impression was that we won't be able to see clickable links in the dashboard to trace from a payment to a transfer to a destination account.

#

Thanks, though!

ruby fiber
#

Ah gotcha, unfortunately I don't think we support that currently for flows where the transfer happens some time after the payment. You could maybe do this as a destination charge with separate auth and capture and change the TransferData before you actually capture the funds. But that would be a bit hacky and would only work if the lesson is within 7 days from the booking https://stripe.com/docs/payments/place-a-hold-on-a-payment-method

Separate payment authorization and capture to create a charge now, but capture funds later.