#artdudejoe

1 messages · Page 1 of 1 (latest)

lone totemBOT
modest rock
#

Hey @hasty trench !

hasty trench
#

Hi 👋

Can you share an example request ID?

modest rock
#

Yes. Copying

#

pi_3LrU3qEBfPkskFWF1JnVznGx

#

That one?

hasty trench
#

And on_behalf_of will only change the merchant of record.

modest rock
#

What's the diff btw merchant of record and the actual account?

hasty trench
#

But since these don't appear to be Direct Charges they will always exist on the Platform Account

modest rock
#

So PaymentIntent is not a "Direct Charge"?

hasty trench
#

You can make a Payment Intent in a variety of charge types. Are you familiar with the different types of charges in Stripe Connect

modest rock
#

I am not

hasty trench
#

Okay well there is a good doc to start with.

#

What kind of Account Types are you dealing with?

modest rock
#

card type

#

really only cards in the US

#

I see ['stripe_account' => '{{CONNECTED_STRIPE_ACCOUNT_ID}}']); is this the difference?

#

Rather than 'on_behalf_of'?

hasty trench
#

No, sorry what type of Connect Accounts are you using?

modest rock
#

"Standard"?

#

Yes, standard.

hasty trench
#

In that case you should be using Direct Charges

#

Which would live on the Connect Account

modest rock
#

I honestly don't see any difference between what I am doing with paymentIntent and this except I replace on_behalf_of with stripe_account. Am I right?

#

On the refund I see charge instead of payment_intent with stripe_account

hasty trench
#

How/where you specify the account is a critical factor for how all of this behaves.

#

It sounds to me like you need to spend some time reading the doc I provided along with all the related child docs. There are some gotchas in there that it will be important for you to understand

#

But with Standard Connect Accounts we highly recommend using Direct Charges

modest rock
#

I've been reading these docs for months now and I've apparently not found a complete solution. For example setupIntent vs paymentIntent vs charges. Server vs JS vs no-code etc. Is there any way you can point at the gotchas just so I know?

hasty trench
#

Wow, that's a lot of unrelated things.

#

Setup Intent - collect payment method details to charge later

#

Payment Intent - charge an amount

#

JS can exist on the Server (Node) and the client

#

The gotchas I was referring to have to do with what Charge type & Account you choose

#

And how that impacts where records are stored, how you make charges, and how you can reconcile revenue

modest rock
#

RIGHT! I am needing both in person (with or without terminals -- a whole different struggle) and saved payment methods/setup. All in a Connect environment for hundreds of SAAS customers.

#

All in a custom server based solution that I am adding to an existing scheduling solution.

#

10's of thousands of Stripe Customers

hasty trench
#

Okay well this forum is best for helping people with specific questions about specific APIs. These questions are all a bit nebulous and hard to parse

modest rock
#

I feel your pain.

#

Let me test a bunch more to see if I can't get these payments to show up in the right places using the strategies you pointed to.

#

Stripe does a whole lot more than all the extra-specifics that I need so that has been confusing. Especially after writing for Authorize Net for 15 years.

#

One last (well two) question: If I may?

#
  1. when you say "Charge Type" you mean ['card'] vs others, right?
hasty trench
#

I'm referring to the charge types doc I provided above

modest rock
#

Ok. Very cool.

#
  1. when you say "Account type" you mean "Standard" vs "Express" or "Custom"?
hasty trench
#
  1. Yes
modest rock
#

YAY. I got something right today!

hasty trench
#

FYI we refer to ["card"] type stuff as Payment Methods

modest rock
#

Nomenclature. yep

hasty trench
#

Yeah, it helps with clarity when asking questions

modest rock
#

I am a hack without any training beyond a couple books and tons of online resources that happens to have built full featured online apps that seem to be very useful. Learning more as we speak.

hasty trench
#

As another who self-taught programming, web dev and the like my recommendation would be to build a really simple, dumbed down test integration (using a personal account and test API keys).

#

You can get a much better insight into how the APIs behave and work together

modest rock
#

Yep. Sandboxing is my friend.

#

I've already deleted the whole test data set several times.

#

I just noticed last week that these payments were in the wrong place.

hasty trench
#

By "wrong place" you mean on the Platform?

#

If you read the third column in the table about the different charges, it helps explain why different charges live on different accounts

modest rock
#

Yes, not in the Connect account but in the Platform Account.

hasty trench
#

For Destination charges, the customers interact with the Platform (like Uber or Lyft). In that case it makes sense that the payments are on the platform not the connect account (individual drivers)

modest rock
#

Okay. So if I let them live initially on the Platform account but want to distribute balance (after your fees and mine eventually) how do I do THAT? Because maybe I process these payments on the Platform Account and then do payouts based on on_behalf_of

hasty trench
#

That would depend on the type of charge

modest rock
#

I can see that

hasty trench
#

But if you read the docs for each charge type it lays out the funds flow very clearly

#

and you don't do payouts based on on_behalf_of. Use the transfer_data parameter

modest rock
hasty trench
#

Right, that's the doc I linked earlier.

#

There are separate related pages that detail exactly how the call the APIs for each type of charge

modest rock
#

Gotcha

#

in a good way

#

The onion is thick with layers

hasty trench
#

Yep, that's why the docs get so nested

modest rock
#

That doc was breadcrumbed back one step from the one you sent me.

#

Gonna go read and play with some payments and customers and connects

#

Thanks Snufkin, Have a good weekend