#james-checkout-acc

1 messages · Page 1 of 1 (latest)

exotic etherBOT
#

Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

agile junco
#

Customer in question: cus_F02xKNsXF6sWqd
Price in question: price_1ODZhm2PFDCON6VbTqHqXWLN
Payment in question: pi_3OEZFt2PFDCON6Vb1D8lohZz
The IP address of the confirmation request is identified as coming from Canada
https://dashboard.stripe.com/logs/req_c51x6x6UxIHtEL

wind anchor
#

@agile junco what's your exact and clear question?

agile junco
#

The Customer is only presented USD even though they are in Canada.
I'm using Stripe's automatic currency conversion feature, so during checkout it should automatically be presenting this customer with CAD but it is not - it is presenting USD.
I'm using Stripe::Checkout::Session.create to create the checkout session with session_data that looks like:

{
client_reference_id: 1,
line_items: [{price: "price_1ODZhm2PFDCON6VbTqHqXWLN", quantity: 1}],
mode: "subscription",
success_url: payments_success_url,
cancel_url: payments_canceled_url,
customer: "cus_F02xKNsXF6sWqd"
}

There was also a lot of effort leading up to this point around the documentation clearly stating that I would be able to change their default currency from USD to CAD, but that ended up being false - once a customer has a subscription, their default currency is no longer changeable.

#

I don't feel like I can do anything differently on my side of things, so I suppose my exact and clear question is 🤔 Can you fix things so this customer is presented with CAD currency during checkout?

wind anchor
#

Does it work if you force the currency (just to make sure)?

#

james-checkout-acc

agile junco
#

I haven't tested that because it would require significant backend changes to my codebase to make things work for the customer in the live site

I'll take a minute to see if there's a way for me to test in a console session on my own, without involving the customer & deploying new code

#

If helpful - I've tried changing the Customer record in the hopes of Stripe being able to correctly present the CAD currency:

  • canceled their subscription
  • removed their payment method
  • removed existing credit balance (which was in CAD) from their account

These changes didn't help - the customer was still presented with USD

wind anchor
#

I haven't tested that because it would require significant backend changes to my codebase
It's literally passing an extra parameter to a function for 2 minutes to verify. I'm sorry but you do need to pause and try this if you want me to help you in real time here. There's nothing significant about the change just to test locally

#

I'm trying locally for example, I created a Customer, subscribe them to a EUR Subscription then canceled it. Customer's default currency is now EUR. Then I create a Checkout Session with a Price that has USD/EUR/GBP as currency_options and the Session is now in USD as expected.

agile junco
#

Ah - your phrasing suggested to me that you expected me to test this with the customer in the live site. Doing all that would be significant.
Which is why I also noted that I would be seeing if I could do this myself locally without involving the customer.
I'm working on that now.

#

OK, yeah, forcing currency in that Stripe::Checkout::Session.create call does result in a Stripe::Checkout::Session object with currency set to CAD

#

further verified by visiting the provided URL & seeing the CAD pricing

wind anchor
#

Okay, now can you use the same Customer and give me a Checkout Session id for me to look at?

agile junco
#

I ran two tests ☝️ so I can share two:

  1. This was without currency set: cs_live_a1nOjxDigXlIqGlBB1DA7f3P2qf7hZL4dRNHXA5ASxPFaykir0s0zpszEf

  2. This was with currency set: cs_live_a1FVjrv5p3n8rFbyDtW0zrU8j2BXY9sqOIuoj9Zxe0riVugG1WBut8MHZm

I'd 🤷 kind of expected the first one to always display USD since I ran it on a server in the US and the default currency for the customer is USD, but 🤷

wind anchor
#

(looking, will take a while as Discord is busy and this situation is not easy to reproduce :p)

agile junco
#

Yeah, I see all these conversations! 😰

wind anchor
#

oh boy it's all in Live mode? Why isn't all of this done safely in Test mode?

agile junco
#

I don't have that customer in test mode, they're an actual customer with a real problem

If there's a way to copy the data from live to test, I'm happy to set that up

wind anchor
#

You, as the developer, should be able to reproduce a similar situation in Test mode end to end though right?

#

Like where are you located? Canada or US?

agile junco
#

US

wind anchor
#

Okay, so create a Customer, force it to CAD with a Subscription in CAD first, then cancel it. Then create a Checkout Session with a CAD Price that has a currency options in USD and see if you see CAD or USD

#

That seems to work fine for me locally at least in Test mode when I do this.

agile junco
#

Yeah, I'd definitely expect the specified currency to be used in a session if I forcefully set a currency.
My issue is when I don't set a currency and the system doesn't automatically see that it should be CAD.

Given that info, does this test make more sense?

  • create a new price in CAD and a USD option
  • create a customer
  • create a subscription in CAD for that new price
  • cancel it
  • create a session without specifying currency for the same price
  • verify that it is USD not CAD
wind anchor
#

yes, that's what I tried locally on my account (with EUR) and I saw the right currency.

#

If you also see USD in that case then the next question is why your customer sees USD and not CAD, which could be because their IP is detected to be from Canada

#

I'm trying again to make sure I didn't mess up something while testing, this makes my head spin a little.

#

ah I think I did mess up in my tests and mixed up my Price ids

#

Here's what I did

  1. Create a Customer
  2. Create a Subscription in EUR and then cancel it
  3. Create a Checkout Session with a Price that is GBP by default but with currency_options for EUR and USD
  4. Load it from the US -> See GBP anyways
  5. Do the same thing with currency: 'usd' and it works totally fine and shows USD

So to me it seems like we have a bug where if the Customer has a default currency set we will incorrectly rely on that currency instead of properly rendering the local currency.

agile junco
#

Here's a bag of info...

Product: prod_P347GfZO6DcnA9
Customer: cus_P348fV9LjL9LMJ
Session: cs_test_a17GsDQbjraDbS77wJY0SUKfthpTzVYKEZKfQSWUXXLyTnAvv8a4tW4NLp

I did the first 4 steps ☝️ in the Stripe web UI
I did the 5th step (create session) in my local rails console ... it resulted in a session in CAD instead of USD

wind anchor
#

And it seems you got to the same conclusion.

#

The mistake I made earlier was that I had a Product with USD currency and GBP/EUR as options and I incorrectly use that Price id instead of the EUR one with GBP/USD as options 🤦‍♂️

agile junco
#

Yeah, this seems like an accurate assessment

So to me it seems like we have a bug where if the Customer has a default currency set we will incorrectly rely on that currency instead of properly rendering the local currency.

wind anchor
#

So yeah it looks like a bug though you could reason that... using the Customer's default currency in that sense makes a lot of sense too. They already paid in that currency

#

I feel like if we fix this, next month someone will come ask for the opposite 😦

agile junco
#

(and the site docs state that I can change a customer currency as long as there isn't a current subscription, but in my experience, I cannot change a default currency after any subscription has been created - it does not need to be active)

wind anchor
#

that's not really what the docs are trying to say

agile junco
#

They are failing then 😬

wind anchor
#

Between 2012 and December 2022, once a Customer had a Subscription (or anything that sets the default currency) they were forever locked into that currency for Subscriptions. We lifted this limitation only in December 2022 and now you can create a new Subscription in a different currency after the fact (which swaps the default currency for you)

agile junco
#

On the topic of this issue I have, and its relation to how others use Stripe (your note about how next month, etc)...
I suspect that I'm the one a little off in my particular scenario ... I've been using Stripe for a long time and my initial use was entirely USD & it might not have even been possible to accept other currencies at that time (can't quite remember)
So I have hundreds of people on this old USD-only subscription that I'm working with to get them onto one of the newer subscriptions I have ... So for me it's best for Stripe to re-determine their currency, because the first time that happened it wasn't based on any sort of reality - it was just forced
But I can see a situation where others have a clean start with multiple currencies, so that initial determiniation of their currency was correct & re-determining it wouldn't make sense
🤔 tough one

wind anchor
#

yeah to be clear I do think it's a bug we should fix. Just that's my take and I see the other side too

#

but I'm reporting the bug to the product team because I agree it would make sense to fix it

#

In the meantime you likely have to ask your customer which currency they prefer first and then force it in the API like I showed you earlier

agile junco
#

For the docs, though, I read this page as clearly stating that - provided the customer meets the requirements - their default currency can be changed:
https://support.stripe.com/questions/setting-a-customers-default-currency

You can change the customer’s default currency if there are no active subscriptions, quotes, or other Billing objects in the customer's current currency.

That "active subscriptions" piece is wrong in my experience - the customer has to never have ever had any subscriptions

wind anchor
#

yeah that's what I said earlier you're just misunderstanding this because you are focused on your own narrow use case

#

You can totally have a Customer with EUR as the default currency and then you create a USD Subscription instead and it will change their default currency to USD

agile junco
#

but isn't that page discussing the action of changing the default currency value?

Customer created with EUR default currency
Cancel subscription
Change customer default currency to USD

This is not possible, because a subscription existed. That page suggests it should be if the subscription is canceled. So does this page https://support.stripe.com/questions/why-are-customers-locked-to-a-specific-currency-and-can-not-be-moved-to-a-price-in-another-currency
which lists "Active Subscriptions (status other than “canceled”)" as a blocker ... as oppposed to "Any Subscriptions" which is the real/true blocker (in my experience)

#

ooh, great example - that test customer I created ... cus_P348fV9LjL9LMJ
You cannot change its default currency any more, even though there is no active subscription

#

I don't know how tough it is for you to check that out, so here's a screenshot of the disabled currency pull down

wind anchor
#

ah yeah you're right. Ugh this used to work. I guess you found another bug 😅

agile junco
#

it's Panera up in here 🤣

#

Alright, so...

until/unless the automatic currency detection bug is fixed, I'll need to manually set the currency for the checkout session for that user & for anyone else who experiences this issue

relatedly, if that pull down menu issue gets fixed before the automatic currency detection bug does then I might be able to use that to get people onto their real currency

#

Can I provide you with any further info that will help you report these bugs?

wind anchor
agile junco
#

😅 kinda scary since that currency detection feature feels pretty "core tech" from the outside ... I'll report as well

wind anchor
#

I mean it's an extreme edge-case you're hitting, you have to give us that. I'm not saying it's not frustrating but it's also extremely rare to end up in this situation

exotic etherBOT
agile junco
#

Yeah, anyone who rolls out their service in a single currency and then later adds currencies would be the only people affected