#Rulian - Connect

1 messages · Page 1 of 1 (latest)

dim otter
#

Hello! Connect is what you would need to use for this, but can you tell me more about what you're trying to build so I can give you a good recommendation?

swift mesa
#

Basically its a email paywall for people who provide advice or have an audience

#

So effectively, user B (who is a guest) is trying to send a message to user A (who is a registered member of my platform) and needs to pay in order to do so. The amount is determined by user A (my user)

#

I would like to avoid escrowing the money or holding financial information on my system for safety reasons

#

so I'd like to use something like express connect but very very few users actually went thru the express process on my platform

#

I'd like to simplify it by finding some other means of paying them

#

Even if I charge the user and eventually send them a payout by some other means, i'd still like to rely on some financial service to hold that credit/debit system for me

#

but ideally I could just pay user A automatically and not have to escrow at all

dim otter
swift mesa
#

With this option a user onboarding onto my platform would still need to go thru the connect process in order to be able to receive payments correct?

dim otter
#

Yes.

#

In order to receive money they need a Stripe account of some kind, be it Standard, Express, or Custom.

swift mesa
#

That is the best case scenario but out of about 100 sign ups only 2 people went thru that process

#

issue is my platform is new and users are kind of like "why do you need my bank info?"

#

Lets say I choose the escrow money option and perhaps pay them out only once they reach $100 in credit or something. Does stripe provide me any option to act as my "bank" so I dont have any of that data on my side?

#

Cause I'm thinking once they have decent money to collect they'll be more willing to go thru the connect flow

dim otter
#

Stripe is also not a bank.

#

If someone wants to get paid they need to provide their bank account to enable that to happen, and that's what the Stripe account is for.

swift mesa
#

yup, understood, i'm guessing i'll need to find a place to store financial information so my servers don't need to have financial audits

#

Thank you for your help!

dim otter
#

With Standard or Express you wouldn't store financial information on your end at all, Stripe would.

swift mesa
#

yup i understand their CC info wouldn't go thru my backend. But "This user received $20 dollars and hasnt been paid yet" would be something on my servers. Which is just info i dont want to be responsible for cause losing that would lose people's real money

#

I'll be using stripe to charge users and pay users out

dim otter
#

That's not how it would work with Standard accounts and direct charges.

swift mesa
#

but I'll need to find a place to store that accounting table

#

sorry i must be confused then

dim otter
swift mesa
#

Yes, that's the route I initially took, direct payouts with connected accounts. But issue was users dropped off because of the onboarding process

#

I still have that option, i'm just looking to see if I can solve that issue with different options

dim otter
#

Yeah, there's no way to not have them go through onboarding.

swift mesa
#

yea, i may pair stripe with something like https://aws.amazon.com/qldb/ just so I know the credit/debits I store are 100% correct.

At least until the user has enough money to go thru onboarding on connect, once they do I can pay them out directly.

This wouldn't be an issue if users didn't drop off. I 'm 100% confident its because of the fact my platform has no trust. But it also can't operate unless users go thru it. So i'm kind of stuck right now

wheat berry
#

Perhaps the confusion is that only "users" who want to RECEIVE money need to go through on-boarding - "customers" who want to PAY would not need to be (and shouldn't be) connected accounts, and would not need onboarding. If ALL of your users both pay and receive (an unusual situation), then you can think of each user, from Stripe's perspective, as two separate entities - a "customer" who simply pays, and if they later want to BE paid they onboard as a connected account.

#

In general, Stripe payments are one-way - FROM customers who pay TO users who are paid.

swift mesa
#

Correct, only the platform "users" need to go thru onboarding, the guest just pays like a regular purchase on the website with a credit card

#

What I'm leaning towards is going with the stripe + qldb approach which is solving the problem more at a product level.

I will charge the user $5 for example to contact user A
i will write to qldb that i owe user A $4.50
user A will see their piggy bank growing - but the way to claim is to go thru stripe onboarding.

Once they've onboarded, I will be able to pay them directly.

Its more complicated but I think it offers best of both worlds

wheat berry
#

I'll note that model leaves your platform responsible for refunds, disputes, chargebacks, etc etc for such transactions. Not necessarily a bad thing - it is my own model - but my business "users" inherently onboard. I'm aware of and building for the potential issues (including in my overall business design and model).