#masonhale - Connect Express
idle haven
Hi 👋
When you create the customer, are you passing in the Stripe Account for your Express Account?
https://stripe.com/docs/api/connected_accounts
sick current
I am not. I think that's the extra detail I was missing. I've been using the "on_behalf_of" parameter to create PaymentIntents connected to the connected accounts, and I've been creating Transfers to the connected accounts, but I hadn't needed to pass this extra stripe_account param before. Thanks for pointing it out.
idle haven
Yeah, "on_behalf_of" is how you associated the charges with the express account. But to do things like create Customers or Payment Methods on your Connected account you'll want to use the Stripe Account header.
Then the record will "belong" to them
And you don't get those "this customer does not exist" errors
sick current
Ok, thanks
idle haven
Happy to help 👍
idle haven
hello, I'm trying to create a customer with an attached payment method (for future use), but I am getting the error message The payment method you provided has already been attached to a customer. Can one card not be shared by multiple customers? Or rather, does a PaymentMethod uniquely map to a specific card number?
sick current
Follow-up: hello, I'm trying to create a customer with an attached payment method (for future use), but I am getting the error message The payment method you provided has already been attached to a customer. Can one card not be shared by multiple customers? Or rather, does a PaymentMethod uniquely map to a specific card number?
sick current
great minds...
idle haven
Or rather, does a PaymentMethod uniquely map to a specific card number?
Nope, I've mapped our test cards to many Payment Methods
Can one card not be shared by multiple customers?
Payment method objects are specific to a single Customer object
sick current
Another thing I've discovered, when I create a PaymentIntent from my Connect Express account, using "on_behalf_of" parameter to a connected account id, the PaymentMethod that ends up being attached to the PaymentIntent cannot be attached to a Customer created in a connected account. When I attempt this, I get this error OAuth key or Stripe-Account header was used but API request was provided with a platform-owned payment method ID. Please ensure that the provided payment method matches the specified account.
Ok, re: card to many PaymentMethods, I must be doing something else wrong... will keep trying.
idle haven
I would review the different ways you can make charges for your Express accounts: https://stripe.com/docs/connect/destination-charges
There are a couple different approaches depending on how you want to
- Assign responsibility
- Collect fees
sick current
Because we very frequently have complex multi-party transactions, we assign a transfer_group and then manually create Transfers to each related party when payment_intent.succeeded is received.
The way we collect fees is by deducting it from the amount transferred, as described here: https://stripe.com/docs/connect/charges-transfers#transfer-options
idle haven
Okay. With Separate Charge and Transfer, you (as the Platform) do the charging yourself. The customers and payment methods are yours and belong to your account.
Then you disperse the funds for the goods/services via the transfers to the Express accounts
sick current
So, to make certain I understand, the implication of this is that I cannot create a Customer in a connected account, and then attach a PaymentMethod attached to a successful PaymentIntent (created in my platform account). Is that correct?
idle haven
If the customer exists on the connected account and you want to use a Payment Intent to attach a Payment method, they all need to be made on the connected account.
If you are using SC&T, you'll want to create the Customer, Payment Method, and Payment Intent on your account
sick current
Q: is there another way to do split payments between connected accounts, apart from Separate Charge and Transfer? I ask, because I just recently noticed a small note saying that Transfers are not available in Australia and Canada, and adding support for those 2 countries is next up on my todo list. Without Transfers, I don't know how I can do the split payments I need to be able to do.
idle haven
we very frequently have complex multi-party transactions
In this case, your account is the only one that would have the full picture of what's going on so it makes sense your account would process the payment
sick current
Screenshot of message warning that Transfers are not available in Australia and Canada
dry nebula
what country is your platform account in? I'm guessing that you have connected accounts based all over the world?
sick current
Our platform account is in the US. We have customers in about 12 countries. A major reason for our decision to switch to Stripe (implementation currently in progress) was to gain access to more international markets. We currently use a very old PayPal integration for those customers.
Our PayPal integration doesn't support multi-party transactions, and we don't want to do the dev work requirement to add multi-party split payments to that platform.
dry nebula
hmmmm, onesec, let me check my own test account to see if I see that same warning
it's interesting that you're seeing that error but technically Transfers to those countries are supported : https://stripe.com/docs/connect/cross-border-payouts
I'd suggest writing in to Stripe Support, they'll be able to help check on why it's showing that warning
sick current
ok, thanks. I'll check with Stripe support
Also, to be clear, I need the Transfer feature in addition to Payouts. I understand from the documentation these used to be the same thing/related, but now are more separate. A Transfer is now a transfer of funds from a platform account to a connected account. A Payout is a transfer of funds from a (connected in my case) account to their external bank account.
dry nebula
yep, understood, both would be supported
sick current
Another question: I'm trying to implement a feature where an end consumer can authorize one of our connected account to charge their payment method for a limited amount but potentially months in the future. This is to enable swim teams to charge "penalty fees" via credit card to parents who don't honor their volunteering commitments. The best way I've found to do this is with "setup_future_usage" on a PaymentIntent, and to attach the Customer and PaymentMethod (which is working now, that I'm not trying to attach to a connected account, thanks). We then save in our system references to that Customer and PaymentMethod and the amount approved, and when that approval expires. My question is: what is the best way for me to remove the ability to charge that PaymentMethod on the Stripe platform? I'm worried that deleting the Customer or PaymentMethod may delete other data associated with those objects, which I probably do not want to do. Any ideas?
dry nebula
is it possible that the same PaymentMethod is being used to pay something else?
sick current
The payment method would have previously been used to pay a PaymentIntent with a setup_future_usage parameter (which captured the PaymentMethod)
The main thing I want to do is reduce the risk surface area of having an open ended "card on file" in the stripe system, when I only really need it for an approval of a finite $amount and a finite amount of time.
dry nebula
i think it's fine to "delete" the card. It isn't necessary to delete the Customer
sick current
Ok, thanks.
Ok, so PaymentMethod.detach should do the trick, right?
I don't see a PaymentMethod.delete method
dry nebula
yep, it's PaymentMethod.detach
sick current
👍