#dgsunesen-eventually-due-status

1 messages · Page 1 of 1 (latest)

red holly
#

Hello. Hmm, good question. Not sure how we can emulate this status as eventually_due requirements are when an account reaching certain thresholds

#

Let me check

gaunt laurel
#

Thanks 🙂

#

It would be really nice to somehow force it to end there, as it's a situation we need to cover on our platform 🙂

red holly
#

Basically there's certain test cards you can use which will trigger volume thresholds on the account and thus eventually_due requirements

gaunt laurel
#

Thank you 🙂 Let me have a look 🙂

#

Okay, so I'm a bit confused how this is done. How our platform works right now:

User 1 creates an account and adds a bank account. Right now we can either have it all verified immediately or have it be currently_due and then go through the verification process.

User 2 has a task that she wants to get done. She has added a credit card to pay with.

User 1 takes on the tasks.

User 2 eventually pays User 1 for doing the task.

How, considering this flow, would I test getting User 1's account in a eventually_due state.. What we would actually like to test is that, when User 1 creates the account and adds the bank account, that we can have it be in eventually_due so that we can test prompting User 1 to verify the account before taking on any tasks

reef mantle
#

I think the guide ynnoj posted covers how you'd get the connected account of 'user 1' into that state, not sure what else I could add.

#

or simply create the account and don't pass all the required information upfront like you do now, so some of it remains due

gaunt laurel
#

business_type: ‘individual’, business_profile: { url: https://myurl.com name: user.displayName, mcc: ‘7299’, }, email: user.email, individual: { address: { city: user.location?.city, line1: isTesting ? ‘address_full_match’ : user.location?.street, line2: user.location?.streetNumber, postal_code: user.location?.postalCode, }, email: user.email, first_name: this.userService.guessFistName(user.name), last_name: this.userService.guessLastName(user.name), phone: user.phone, ...(user.birthdate ? { dob: { day: getDate(user.birthdate), month: getMonth(user.birthdate) + 1, year: getYear(user.birthdate), }, } : {}), }, capabilities: { transfers: { requested: true }, }, ...(userIP ? { tos_acceptance: { ip: userIP, date: user.profileCompletedAt ? getUnixTime(user.profileCompletedAt) : getUnixTime(new Date()), }, } : {}), },

#

This is basically how we create the account

#

and then afterwards we add the account lik

#

{ country: 'DK', account_number: dkIBAN, currency: 'DKK', account_holder_name: user.name, account_holder_type: 'individual', }

#

if we add 01.01.1901 ad the date of birth and this IBAN number, DK5000400440116243, then the account is verified right after

#

if e.g. I use 01.01.1984 as the date of birth, it'll end in currently_due right after

reef mantle
#

yep!

gaunt laurel
#

so looking at this, how would I then, after I add the custom account and add the bank account, get the account into the eventually_due state — is there anything I should skip adding in the process, add differently or ? 😅

#

We tested it using the stripe production environment, there it seemed to do what we would expect; end in a eventually_due right after 🙂

reef mantle
#

try create the account with absolutely nothing

#

like just the country:"DK" and type:"custom" and requested_capabilities and nothing else in terms of KYC

gaunt laurel
#

we already tried that — no luck unfortunately 😦