#oxmarco_connect

1 messages · Page 1 of 1 (latest)

fading lintelBOT
fair harborBOT
#

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.

fading lintelBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1247462639869755410

📝 Have more to share? Add details, code, screenshots, videos, etc. below.

minor lance
#

Hey, I think I found a problem with my code on the way it handles the account.update webhook

if (event.data.object.details_submitted && event.data.object.payouts_enabled
) {
    if (
        event.data.object.capabilities.card_payments &&
        event.data.object.capabilities.transfers &&
        event.data.object.charges_enabled
    ) {
        // save the user as stripe verified
    } else {
        // throw an exception
    }
}
bitter shard
#

Hi
What is the ask exactly here ?

minor lance
#

first of all, is. the nested "if" needed?

#

secondly, what if the account update instead of going from unverified to verified goes vice versa, should I handle that scenario too?

bitter shard
#

What is your use case first

minor lance
#

a stock images marketplace, I am using Stripe connect

# 
return await this.stripe.accounts.create({
        email,
        controller: {
          losses: {
            payments: 'application',
          },
          fees: {
            payer: 'application',
          },
          stripe_dashboard: {
            type: 'none',
          },
          requirement_collection: 'application',
        },
        capabilities: {
          card_payments: {
            requested: true,
          },
          transfers: {
            requested: true,
          },
        },
        business_type: 'individual',
        business_profile: {
          mcc: '5815', // digital_goods_media
          url: `url`,
        },
        tos_acceptance: {
          date: Math.floor(Date.now() / 1000),
          ip,
        },
      });
#

users register first

then I generate onboarding links

return await this.stripe.accountLinks.create({
        account: stripeAccountId,
        refresh_url: 'https://example.com/verified?success=false',
        return_url: 'https://example.com/verified?success=true',
        type: 'account_onboarding',
      });
bitter shard
#

secondly, what if the account update instead of going from unverified to verified goes vice versa, should I handle that scenario too?
1- You need to keep listening to account.updated event
2- Immediately after creating an account, check the Account object’s requirements.currently_due attribute for any additional requirements.
3- Continue watching for account.updated event notifications to see if the requirements hash changes, and reach out to your user for additional information as needed.

minor lance
#

there are quite a few fields on the account.update webhook bag, what should I be watching closely? pending_verification ? or payouts_enabled?

bitter shard
#

You need to watch requirements.currently_due attribute to see if there is any additional required information

minor lance
#

ok, just to be sure, if one of these fields is invalid, can I just call stripe.accountLinks.create again?

#

and Stripe will take care of the user verification

bitter shard
minor lance
#

ok looking at the schema, I should check if the past_due and the currently_due arrays are empty, if they are both empty then the user has been successfully onboarded, otherwise I need to redirect them to the onboarding link

bitter shard
#

Yes!

minor lance
#

excellent, but are you sure then event.data.object.capabilities.card_payments, event.data.object.capabilities.transfers and event.data.object.charges_enabled will be enabled? or do I need to check it specifically

#

I may need to do both to be honest

bitter shard
#

You can add an additional checks, it's ok yeah.

minor lance
#

ok perfect, one last thing

#

got wrong question, I am sorry, here is the correct one

#

I see that connected accounts balance is split into available and pending, but it should be paid directly to the connected account iban. So what is the "available" balance representing then?

#

my reading is that the available balance is what will soon be transfered to the connected account IBAN and once that happens, it is reset to 0

bitter shard
#

The "available" balance represents funds that have been processed and cleared from the Stripe platform and are ready to be paid out to the connected account's bank (IBAN). These are funds from successful charges that are no longer in a 'pending' state due to transaction processing times or potential dispute holds.

On the other hand, the "pending" balance represents funds from transactions that have been processed but not yet cleared. These funds might not be accessible immediately due to possible delays in processing transactions. The delays can be due to bank processing times or additional time held by Stripe to mitigate risks like refunds and chargebacks.

fading lintelBOT
dusky grail
#

👋 taking over for my colleague. Let me know if there's any follow-up Qs I can answer!

fading lintelBOT
#

oxmarco_connect

minor lance
#

hi

#

yes it's not clear if the "available" balance is reset after a payout or not

#

say I have $10.00 in the pending balance, then after a few days I'll see these in the available balance, then what happens?

dusky grail
minor lance
#

ok then it goes to zero after some time

#

when it's paid off

dusky grail
#

if there's no other funds that are entering your balance then yes

#

but in normal cases you would rarely see a 0 available balance

minor lance
#

ok perfect

#

is there a way to speed up pending -> available -> payout transition in test mode?

dusky grail
#

yes

minor lance
#

ok great

#

one last thing, I would like to do some production testing

#

is there a way to wipe out the data on prod?

dusky grail
minor lance
#

why?

#

do I risk getting banned?

dusky grail
#

there are risk factors with Stripe and with the issuing banks flagging you as a potential fraudulent risk

minor lance
#

ok I assumed that, the main problem I see is no matter what, a prod env is always different from a testing env

dusky grail
#

not really

minor lance
#

not doing any prod testing seems just wrong from an engineering perspective

dusky grail
#

at least not from Stripe's perspective

dusky grail
#

that's the part that we don't advise you to do

#

we know that if you're integrating correctly in test mode with Stripe the same behavior will happen in livemode

minor lance
#

which kinda breaks the point of live testing haha
I will keep trying in testmode then, thanks for flagging it

dusky grail
#

sure let me know if you need any more help

minor lance
#

just one confirmation
stripe.balance.retrieve -> returns the available and pending balance
stripe.payouts.list -> returns the bank transfers

dusky grail
#

yes exactly

minor lance
#

ok that was all, thanks again for sticking with me

I feel like a few code examples on the Stripe documentation website would really help

#

happy to provide you code snippets from our several discussions

dusky grail
#

thank you for your feedback