#Nyxi
ember needle
broken plank
I need my test account to operate in DKK
urban helm
Hi 👋 is this for testing a Connect integration?
broken plank
Yes
urban helm
Are you able to use one of the Denmark based test bank account numbers provided here to create an External Account with a currency of dkk?
broken plank
Ah let me try
I couldnt' find that doc
Hmm I can't change the current one. I don't want to create a new account.
Its ID is embedded in a lot of testing
urban helm
Hm, I don't believe it's possible to update an External Account once they've been created.
broken plank
When you say "external account", do you just mean a standard connected account?
It's a normal account, just never activated
urban helm
No, External Account is the name of the object that holds the bank account (or debit card) details for a Stripe account's associated bank account:
https://stripe.com/docs/api/external_accounts
broken plank
Hmm, I've never worked with this object
so I just create a new one of these with the connected account as target, but in test mode?
urban helm
Hm, if you're using Standard Connect accounts, you're using Account Links to onboard those?
broken plank
No, I just created the account and used the Oauth flow
but it was years ago
It's just the same account we've used since then
And no, we don't use account links in production eithr
It was never migrated
urban helm
Gotcha, so let's take a step back. What are you trying to test? I'm getting the impression that you may need to create a new Connected Account, but am not certain.
broken plank
Just various charges on our testing environment but with the connected account in DKK
We need to use DKK to test mobilepay
Not supported for USD, which our test account is operating in
And our system only allows the use of 1 currency to simplify things
urban helm
What country is your current test account based in?
broken plank
US
Doesn't seem like I can change that either. it's greyed out saying I have to "change it in the application", but if I click that link it just takes me to the dashboard
This, specifically
urban helm
Yeah, changing an account's country isn't really possible, and it looks like the US-based accounts can't receive or handle dkk payments or have an external account in that currency. I believe creating a new Connected Account to test with the new currency is going to be the best approach.
broken plank
Alright, we'll have to work with that then
Thanks
I may be able to trick our platform into thinking the account is DKK and just let Stripe do the rest
Since you support charging in any currency, we just actively choose not to let our connected accounts do that
urban helm
Sounds good, good luck and let us know if there is anything else we can help with
broken plank
Sure, thanks
Another question, kind of unrelated. Is there a good way to distinguish webhooks from another in test mode? Say I have a staging envronment running on test mode, but i also develop new stuff locally using test webhooks, and I don't want to send those events to the staging env (or, at least I want that env to simply discard those webhooks)
Like webhook metadata on each event
Looking at evt_1MlYKkL7ilRdQXxEhwT2yyhl, I don't see any elements that would allow the server to tell if this event was triggered by the staging environment or some local test
urban helm
metadata is my recommended approach for that scenario, where you include distinguishing metadata values on every object that you create to help differentiate objects created from one flow versus another.
broken plank
Yeah I was hoping I wouldn't have to do that... its a lot of code to update 🥲
Metadata on the event itself would be very helpful
But I guess that's not really possible
urban helm
Agreed, this is a common pain point that we hear about and something we hope to make easier in the future. Part of the problem is that our system is differentiated between live and test modes, and when further differentiations are made within one of those modes we don't really have context on what is being done, the motivation behind that, or what we should do about it.
broken plank
Would probably require a HTTP-header approach on the SDK
That would automatically set metadata on all objects
Like Stripe-Environment-Name, or whatever, and if you pass that, it does it on its own
Could be a solution
urban helm
Hm, I like that idea. Thinking through it, would it make more sense to sandbox resources based on environment, or allow them to intermingle with any other objects in the corresponding mode?
For instance, if you're creating a Subscription, you have a Product, Price, Customer, and Subscription object. If you're running in say QA environment, should you be able to access Products and Prices created in the Dev environment?
broken plank
I think it's a lot more work to actually sandbox them, and I think in that case you are just expected to create a separate set of accounts for your environment
If you never react to or modify objects from different contexts, there is no problem with having them all in one account and technically accessible
based on the "if you don't mess it up, it won't be messed up" logic
This, of course would require any "list all" methods to filter by metadata
But since your proposed solution is "set metadata on all objects", having this globally accessible by 1 header would help people a lot
It moves the complexity out of users' code and the SDKs and onto the API
untold rivet
Hello 👋
Stepping in as toby needs to step away soon
broken plank
Greetings
I see three ways you could do the header-approach:
- One header, with a key-value in it;
Stripe-Environment: mykey;myvalue - Header prefix matching:
Stripe-Environment-mykey: myvalue- this would also allow users to set any number of key-value metadata by just adding more headers - Fixed key name:
Strip-Environment: myvalue- if you want to control the key on Stripe's end
untold rivet
hmm yeah fair. Typically, I've seen folks create separate accounts for each env which allows them to isolate everything.
broken plank
That is the obvious solution, sure
For connected scenarious though, it's 2 accounts each time
and setting it all up can be quite a lot of work
So if all you need is to not react to webhooks from events created by other environments, this would be a lot easier
Anyway, something to think about
untold rivet
Yeah totally understand 🙂
broken plank
Also just for any other use case, you might wanto set a specific metadata key-value for all objects you create
so being able to do this in 1 place would be helpful
untold rivet
Valid feedback! 😄 Will make sure to pass it on internally