#dgsunesen-custom-account

1 messages · Page 1 of 1 (latest)

opaque jolt
round stirrup
#

just a sec

#

req_2tP8bBz4y56fV0

opaque jolt
#

Seems like that was successful?

round stirrup
#

yeah it actually does??

#

hm..

#

but transfer is pending and not active?

#

but when I seconds after console.log the response I get, when I try to get the connected account, it says that transfer is inactive

#

and that I have to verify the user

#

Later it says capabilities.transfers: inactive and the requirements have moved from pending to currently_due

#

this request ID here e.g.: req_7BdiBxxajWkMIn

#

I don't get why it suddenly changes from pending to inactive and not pending anymore

opaque jolt
#

Are you onboarding these accounts at all? The other payload you shared suggests to me that the account was onboarded and verified

#

Particularly the charges_enabled field

round stirrup
#

Onboarding, as in taking them through your Onboarding flow? What we try to achieve is a custom onboarding, where we create a custom account with basic bank account informations. Then we would for them to proceed on our platform, and have another part do a payment intent on behalf of them to receive money. Then later we will make sure to verify them before any payment can happen

opaque jolt
round stirrup
#

{
"business_type": "individual",
"business_profile": {
"url": "https://shouter.app/public-profile/620270a407441da2734e920b",
"name": "Thomas E.",
"mcc": "7299"
},
"email": "thomas+0902@knoew.com",
"individual": {
"address": {
"city": "Aarhus",
"line1": "Fiskerivej",
"line2": "",
"postal_code": "8000"
},
"email": "thomas+0902@knoew.com",
"first_name": "Thomas",
"last_name": "Ebert",
"phone": "+4550328156",
"dob": {
"day": "",
"month": "",
"year": "****"
}
},
"capabilities": {
"card_payments": {
"requested": "true"
},
"transfers": {
"requested": "true"
}
},
"tos_acceptance": {
"ip": "::1",
"date": "1644327389"
}
}

Shouter®
Få fixet dine to do's eller tjen penge på dine talenter

Find tonsvis af dygtige mennesker til dine opgaver i eller udenfor hjemmet. Alt fra handyhjælp til hundeluftning - bare shout.

#

this is what I see from the dashboard

#

this is the response

opaque jolt
#

You can see the outstanding info on the requirements hash

round stirrup
#

Which errors are you seeing? We should be using test data

opaque jolt
# 
errors: [
        {
          code: "verification_failed_keyed_identity",
          reason: "The identity information you entered cannot be verified. Please correct any errors or upload a document that matches the identity fields (e.g., name and date of birth) that you entered.",
          requirement: "verification.additional_document"
        },
        {
          code: "verification_failed_keyed_identity",
          reason: "The identity information you entered cannot be verified. Please correct any errors or upload a document that matches the identity fields (e.g., name and date of birth) that you entered.",
          requirement: "verification.document"
        }
      ],
#

I guess you're probably using non-test data here and it's failing verification

round stirrup
#

okay okay

#

so something like this?

opaque jolt
#

Yep!

round stirrup
#

oh well

#

then THAT might be the issue we're facing!

opaque jolt
#

To be clear, this won't alleviate this issue in live as you'll obviously be collecting REAL data that still may prompt for verification

round stirrup
#

but can't a user be in a pending mode until we prompt them to verify?

#

because we don't actually want it to succesfully verify at this moment, we want to postpone the verification till later

#

what we experience right now is that we ARE succesfull in adding the account and attaching the bank account info, but the next time we request this account, it's now unverified and no longer pending

#

but will this be fixed with adding the test-dob ?

#

Just to make things clear

We are building a marketplace for users to get tasks done.

  • Some user puts out a task
  • Another users wants to do this task
  • When creator of task accepts the one that wants to do the task, we initiate a payment intent on behalf of the one, that wants to do the task
  • Now, before the payout happens, THEN we want to make sure to verify the receiver of the money
#

so we would like to have the two parties actually get going with the task before we need to verify the receiver of the money

#

so that we're not blocking them in initiating a task by having to ask them go through toe many steps before they can start the task

opaque jolt
#

I think you'll struggle to implement that flow if I'm honest

#

What if the user isn't onboarded/verified?

round stirrup
#

When we want to do the payout?

#

But what I'm trying to get a clear idea of is if it is actually possible to

  • Create a custom account with bank account (not verified yet)
  • Create a payment intent on behalf of this not yet verified account
  • Verify account after payment intent
  • Do actual payout

Can this be done?

#

Of course we will push for and nudge the user to verify the account beforehand, but we don't want to limit them in starting a task before they have verified their account

opaque jolt
#

To be clear, the 'pending' status is a bit of a misnomer. It's just a placeholder badge that summarises the current state of the user (i.e. there's outstanding info)

round stirrup
#

And can we keep this 'pending' status, still do a payment intent on behalf of this 'pending' account and then verify the account before we do the payout?

#

So that we of course make sure that the account is verified and all is in place, before the payout happens (which is of course a requirement to do the payout) 🙂

opaque jolt
#

Which is basically what you've seen in test mode

#

Create a payment intent on behalf of this not yet verified account
What kind of charges are you planning on using?

round stirrup
#

So a creator of the tasks decides the price. The platform will take a cut of this price, the rest goes to the one that does the task

opaque jolt
round stirrup
#

destination charges

#

const paymentIntent = await stripe.paymentIntents.create({ amount, currency: 'dkk', customer: customerId, payment_method: paymentMethodId, metadata, // This parameter instructs Stripe to authorize the amount but not capture it capture_method: 'manual', // Indicate that the customer is not in your checkout flow during this payment attempt. // This causes the PaymentIntent to throw an error if authentication is required off_session: true, // Causes confirmation to occur immediately when the PaymentIntent is created confirm: true, // We're fulfiling the payment on behalf of the Doer, who will receive the money when captured on_behalf_of: doerStripeConnectedAccountId, transfer_data: { destination: doerStripeConnectedAccountId, }, });

#

like so

opaque jolt
#

Yeah, I'd be surprised if that works with a non-verified account. Did you try it?

#

Hmm, maybe I'm wrong:

An account created with only a country is fairly limited: it can only receive a small amount of funds. If you wish to enable payouts and keep the account in good standing, you need to provide more information about the account holder. The required verification information page lists the minimum and likely identity verification requirements.

#

Either way, there's associated risk involved for your business

#

I'd recommend speaking to support about this use case, really. It's not so much a technical limitation but more an understanding of verified accounts capabilities/onboarding: https://support.stripe.com/contact

Stripe: Help & Support

Find help and support for Stripe. Our support center provides answers on all types of situations, including account information, charges and refunds, and subscriptions information. Get your questions answered and find international support for Stripe.

#

Would hate for you to build this integration out only to realise it isn't viable!