#asommer12 - Connect Charges
1 messages · Page 1 of 1 (latest)
- Direct Charges: These examples are showing simplified snippets of the Payment Intent (which is just a way of saying you intend to charge someone). A customer is not required but you definitely can charge an existing customer
- Invoices: If your customer's customers have payment methods configured to be charged automatically and you configure your invoices to progress automatically you can process charges without the end customer taking action
amazing, thank you -- couple of quick follow-ups
- Perfect. So all I would need from MyCustomer is for them to provide me the CustomersCustomer's
customer_id, and I could charge directly against that account. Is that right? - This configuration of "charge automatically" -- is this something that is set up globally by MyCustomer, or individually by my CustomersCustomer?
Given your answer to #2, I'm wondering if there is any reason to use Payment Intents and NOT Invoices? What would be the reason to choose one over the other?
This would depend very much on how you have configured your Connected Accounts. Are they Standard, Express, Custom?
Standard
Hey @viral stratus I need to step away but my esteemed colleague @cobalt flame is here and available to answer your questions.
hey @cobalt flame
I think this thread is relatively short, so I won't repeat my questions in depth
Given Snufkin's answer to #2 above, I'm wondering if there is any reason to use Payment Intents and NOT Invoices? What would be the reason to choose one over the other?
heya! gimme a second to get caught up
hmmmm, i guess in general, greater flexibility and control over how you would like things to work. But at the same time, you're going to have to do more work to implement all of that logic
sorry, I don't follow
you're saying it's additional logic to implement Invoicing than it is to implement Payment Intents?
the other way round, it's additional logic to implement PaymentIntents
PaymentIntents.create() looks to be just one method, am I missing something?
Invoicing provides a number of features to help handle certain situations automatically
as an example, the payment fails for one reason or another, Invoicing can send an email to the customer saying that their payment failed, and ask the customer to provide a new card to pay this invoice
i see
and if I'm doing this with Stripe Connect, then the end-customer gets that email to finish the invoice, and neither I nor my connected-account need to do anything extra?
what happens in the parallel situation with PaymentIntents? what happens if the charge fails there?
additionally, with Invoices, how does the customer pay the Invoice? do they automatically get an email with instructions on how to pay the Invoice? is that all automatically hosted by Stripe? just trying to get a clearer picture of why Invoices is less complicated than Charges -- seems the other way around to me
?
maybe lets backtrack a bit, when you say "handle invoicing and charging the customers"
do the customers expect an Invoice/receipt?
It is not a requirement that the customers get a receipt / invoice
I am building software to help businesses bill their customers. I'd like to be able to execute charges on behalf of my customers through Stripe Connect.
It sounds like if MyCustomers provide me TheirCustomers' customer_ids, then I have the option to use either PaymentIntents or Invoices to achieve my goal
And I am looking for some better understanding of why one might use one over the other
alright, i think you can ignore what i said about PaymentIntents being more complex
i'm finding it a bit difficult to put it into words. It's probably not really correct to say one is more complex than the other. It really depends on what you're looking to do - if the business requires handling Invoices i.e. with credit notes, being able to void / mark an Invoice as collectible or not, then you would use Invoices. Otherwise, if you don't need all of those, then using PaymentIntents would make sense
okay that is super helpful
thank you so much for your thoughts
I'll circle back a little bit later when I have further questions
thanks!
sorry that i kinda went around in circles for a bit, but maybe testing it out in your Stripe account may help you make a decision
👍
yep, how can i help?
going to re-paste an earlier question for context:
FROM ME:
In the Direct Charges section of the docs (https://stripe.com/docs/connect/direct-charges), there is discussion only of payments through a UX. There is no input for a customer_id field in the request (to indicate an existing customer of my customer). Can I specify a customer_id here and will it work as intended?
FROM SNUFKIN:
- Direct Charges: These examples are showing simplified snippets of the Payment Intent (which is just a way of saying you intend to charge someone). A customer is not required but you definitely can charge an existing customer
I just tried this and I got a "No such customer" error
The setup is:
There's Me
My customer, connected through Stripe Connect ("The Connected Account"
My customer's customer, with an existing customer_id=cus_LCaAuGPlsi56r5 . That customerId is from The Connected Account's Stripe dashboard
The Connected Account adds the customerId to my application so that I can charge that customer on their behalf
When I go to charge the customer, though, using Payment Intents, I get an error response that the customer does not exist
const paymentIntent = await stripe.paymentIntents.create({
payment_method_types: ['card'],
amount: amountInCents,
currency: invoice.currency,
customer: customer.stripeCustomerId
}, {
stripeAccount: connectedAccount.stripeAccountId,
});
I don't actually see any examples in the Stripe Connect Direct Charges docs (https://stripe.com/docs/connect/direct-charges) where a customer is charged directly, although @hasty wave said that should work
any insights?
Can you share your account id so that I can take a closer look at how your integration works? You can find your account id by logging in to https://dashboard.stripe.com/settings/account. It'll be in the upper right hand corner and looks like acct_123
You want My Account ID or the Connected Account ID?
my account ID is acct_1K3oS3EzAIHCObFx
your account id
and FWIW the other account that I am testing with (the Connected Account) is acct_1GpgHQGq6hzILqyC
I have a personal and a professional account on Stripe, and I was trying to test my integration by connecting one to the other
The request failed, because the two accounts are not connected to each other.
hmm
can you try creating an OAuth link : https://stripe.com/docs/connect/oauth-reference for acct_1GpgHQGq6hzILqyC to be connected to your platform account
I followed all the steps in the Stripe Connect docs and went through the link flow (in Test, not Live)
It's a separate problem that the Connect didn't work, and I'm not sure why that is
I got a success message, got an accountId, etc
hmmm, onesec, looking
the response I got from Stripe Connect was acct_1KWAuhRTskxyiiS0
so here's what I'm wondering
the account id is unique to each account. So acct_1KWAuhRTskxyiiS0 is a different Stripe account
right
okay
so here's what I'm wondering:
I have two accounts:
acct_1K3oS3EzAIHCObFx PlatformAccount
acct_1GpgHQGq6hzILqyC PersonalAccount
I tried to Connect my Personal Account to my Platform Account through Stripe Connect, and Stripe returned the following AccountId:
acct_1KWAuhRTskxyiiS0
why, using my personal credentials, would Stripe Connect have returned a different AccountId during Connect?
i am going to go through the Connect Flow again right now
to see if I get the same result
this time I got a new value: acct_1KWBNoRDE6SUwTFN
my Stripe Connect flow works perfectly, but I'm getting a new value as the resulting accountId each time...
it's not the accountID associated with the credentials i'm using
is that normal?
that's connect onboarding
Connect Onboarding will always create a new connected account
if you want to connect an existing account, you're going to need to use OAuth
ahhhhhhh I see
but there's a caveat, Platforms that use read_write will be able to connect to the user's existing account as long as they're the first platform to connect.
i don't follow
if those business are already connected to another Platform account
you won't be able to connect to their Stripe account and create a charge on their Stripe account
okay
so then help me understand the best path forward
I am a Platform
my customers have existing Stripe accounts with existing customers
I need to be able to charge their customers on their behalf
how do I do that?
honestly, Stripe Connect probably isn't the best use case for your business model because of the limitation i mentioned
why do you want to execute charges on these business's behalf?
Stripe Connect is what was recommended to me by the Stripe representative at YC...
Why? This is the core of my business
I provide billing software and determine charge amounts
My customers want me to execute those charges on their behalf when I determine the amount to charge
This seems like the same use-case that any billing software would have
Is there a better way to do this?
gimme a while to think about this
https://stripe.com/docs/connect "Enable other businesses to accept payments directly...like Xero"
this is precisely my use-case
let's take a step back for a moment
I have zero doubt that Stripe Connect is the right path forward here -- it's all over the docs and it's in my recommended package from Stripe after filling out the survey
"Creating a connected account" -- is there a way to connect an existing account instead of creating a new account when someone goes through the Connect Onboarding?
that seems like the simplest thing here if it can be done
i have a hard time believing that it cannot be done
consider the scenario where a business owner sells products on Shopify and Etsy and Amazon -- they definitely don't need different Stripe accounts for each, do they?
like their single Stripe account should be connectable to other platforms, right?
So you can connect to an existing Stripe account, but only if that Stripe account doesn't already have another platform connected to it
does that make sense?
so assuming i'm somehow connected to platform A already. I wont be able to connect to your platform using this same account.
yep that's right
okay -- does it explain that anywhere?
is there anywhere I can find more info on this before I re-implement?
i did the connect work last night and saw no mention of this...
https://stripe.com/docs/connect/oauth-changes-for-standard-platforms
Platforms that use read_write will be able to connect to the user's existing account as long as they're the first platform to connect.
what does read_write mean please?
and rather, when I say "does it say anywhere," I am referring to the fact that EXISTING STRIPE ACCOUNTS can get connected to my Platform, whereas without OAuth they cannot
read would mean to only access information, write would be to perform some kind of action on the connected account. Direct charges would constitute a write action on the connected account.
it's probably not very explicit - https://stripe.com/docs/connect/standard-accounts
CONNECT ONBOARDING
This is the recommended method for creating standard accounts. If you’re an extension or an application that needs access to an existing account so you can provide services to your users, you can still use OAuth.
ahhhh, i missed that little box
thank you so much
one final question
OAuth is a different paradigm as far as I know
wouldn't OAuth require my Connected Account to authenticate each time they wanted to do something?
you can think of OAuth as a one time authorization to give your platform permissions to do stuff
okay
but "one-time"
that means if I wanted to do recurring billing every month
then OAuth would not work
because my "connected account" would need to re-authorize each month
the authorization lasts forever, unless the connected account or you decides to deauthorize that connection
rihgt?
ah okay
so the Connected Account goes through OAuth one time, and then I have the ability to act on their behalf until they revoke that ability, right?
yep
(unless they're already on another platform)
okay cool
thank you
last question:
because I'm still struggling to understand why this is the case
it seems like the Standard Connect flow is pretty limiting then, no?
Like in the Shopify or Xero examples used in the docs, that means that each merchant needs to create a new Stripe account each time they work on a new platform?
I am effectively Shopify in this example
pretty much, yep, the connected account user will have to create a new Stripe account each time the work on a new platform. Unless the connected account are attempting to connect to an extension - which only needs read access
the reason why this change was implemented was to isolate processing activity. Previously all platforms connected to the connected account would have full read_write access to everything in the connected account which is...not great
right that makes sense
So, please correct me if I'm wrong, but now my decision is:
-
Use Standard Connect, meaning new Connected Accounts for each user. These users will therefore NOT be able to bring their existing customers with them, right? (Or is there a way for them to bring their existing customer relationships over?)
-
Use OAuth, and hope my customers aren't already in another Platform
- There is a way to migrate existing customers - https://stripe.com/docs/security/data-migrations/copies
- I would say you can use OAuth all the way, OAuth would also allow the connected accounts to create a new connected account.
you're welcome! Feel free to reach out again if you need help!