#ayeeeeeeeMon
1 messages ยท Page 1 of 1 (latest)
How exactly are you creating these charges? Can you share an example?
I have tried using the actual card number with our integration, and also with an api call like the following with the token:
curl --request POST
--url https://api.stripe.com/v1/charges
--header 'Authorization: Basic ******'
--data 'amount=2000¤cy=usd&on_behalf_of=[myConnectAccount]&transfer_data[destination]=[myConnectAccount]&source=tok_visa_triggerChargeBlock'
Can you share the request ID for this from your dashboard?
https://support.stripe.com/questions/finding-the-id-for-an-api-request
Hmm, the request looks fine ๐ค
Let me dive a bit deeper
๐ stepping in
Hmm yeah this should block charges on the account. Give me a couple mins to test something
Ah I don't think that account has any future requirements
Those cards are only to move along with the tiered verification process
Meaning when something will eventually be due in the future, you can use those cards to simulate that thing not being completed in time and then charges being blocked and then payouts being blocked
So the cards won't do anything unless there are actual outstanding future requirements on the account
ahhh ok, thats good to know. Is there anyway to simulate just the charges being blocked through onboarding. For our integration with Stripe Connect, we show a specific error messages when charges is blocked, but payouts is enabled. However, I haven't been able to replicate that scenario, to test it out.
Hmmm
I'm not seeing a way to do that
I think you are best off just mocking a response here for your testing in this case
So basically you could just mock charges_enabled: false and test with that if that works for you?
yeah, i am leaning toward that for now
I can't really think of a scenario overall where we disable charges but not payouts....
But you have seen that happen live?
Like most often it is either disable just payouts or disable both
Thats good to know. We haven't gone live with our integration with Stripe Connect yet, so we were just thinking of all the scenarios we might have to handle
Yeah I'm not 100% on the above... maybe there is some niche scenario I'm not thinking of.
But I haven't really seen that be the case
Having a check for it just in case is always a good idea
We could always implement this in the future for instance and would not consider that breaking
So yeah, I'd recommend just mocking handling the different variations of payouts_enabled and charges_enabled from your account.updated event
Will do, thanks for the help/clarifications!
Sure thing!