#asommer12 - Connect Charges

1 messages · Page 1 of 1 (latest)

hasty wave
#
  1. 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
#
  1. 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
viral stratus
#

amazing, thank you -- couple of quick follow-ups

#
  1. 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?
  2. 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?

hasty wave
#

This would depend very much on how you have configured your Connected Accounts. Are they Standard, Express, Custom?

viral stratus
#

Standard

hasty wave
#

Hey @viral stratus I need to step away but my esteemed colleague @cobalt flame is here and available to answer your questions.

viral stratus
#

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?

cobalt flame
#

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

viral stratus
#

sorry, I don't follow

#

you're saying it's additional logic to implement Invoicing than it is to implement Payment Intents?

cobalt flame
#

the other way round, it's additional logic to implement PaymentIntents

viral stratus
#

PaymentIntents.create() looks to be just one method, am I missing something?

cobalt flame
#

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

viral stratus
#

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

#

?

cobalt flame
#

maybe lets backtrack a bit, when you say "handle invoicing and charging the customers"

#

do the customers expect an Invoice/receipt?

viral stratus
#

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

cobalt flame
#

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

viral stratus
#

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!

cobalt flame
#

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

viral stratus
#

👍

viral stratus
#

hi again

#

are you still with me?

cobalt flame
#

yep, how can i help?

viral stratus
#

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:

  1. 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,
      });

#

any insights?

cobalt flame
#

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

viral stratus
#

You want My Account ID or the Connected Account ID?

#

my account ID is acct_1K3oS3EzAIHCObFx

cobalt flame
#

your account id

viral stratus
#

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

cobalt flame
#

The request failed, because the two accounts are not connected to each other.

viral stratus
#

hmm

cobalt flame
viral stratus
#

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

cobalt flame
#

hmmm, onesec, looking

viral stratus
#

the response I got from Stripe Connect was acct_1KWAuhRTskxyiiS0

#

so here's what I'm wondering

cobalt flame
#

the account id is unique to each account. So acct_1KWAuhRTskxyiiS0 is a different Stripe account

viral stratus
#

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?

cobalt flame
#

are you using OAuth or Connect Onboarding?

viral stratus
#

neither -- connect for standard accounts

cobalt flame
#

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

viral stratus
#

ahhhhhhh I see

cobalt flame
#

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.

viral stratus
#

i don't follow

cobalt flame
#

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

viral stratus
#

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?

cobalt flame
#

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?

viral stratus
#

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?

cobalt flame
#

gimme a while to think about this

viral stratus
#

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?

cobalt flame
#

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.

viral stratus
#

okay understood

#

and to do that, I MUST use the OAuth flow?

cobalt flame
#

yep that's right

viral stratus
#

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...

cobalt flame
viral stratus
#

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

cobalt flame
#

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.
viral stratus
#

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?

cobalt flame
#

you can think of OAuth as a one time authorization to give your platform permissions to do stuff

viral stratus
#

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

cobalt flame
#

the authorization lasts forever, unless the connected account or you decides to deauthorize that connection

viral stratus
#

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?

cobalt flame
#

yep

viral stratus
#

(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

cobalt flame
#

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

viral stratus
#

right that makes sense

#

So, please correct me if I'm wrong, but now my decision is:

#
  1. 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?)

  2. Use OAuth, and hope my customers aren't already in another Platform

cobalt flame
viral stratus
#

awesome

#

thanks so much for your help, Alex

cobalt flame
#

you're welcome! Feel free to reach out again if you need help!