Ability to put the Stripe fee on the "destination", when using "destination" parameter

[Mattias Fjellvang]

As a market place, we would like to use Stripe Connect, but have the opportunity to pass on any Stripe fees directly to the connected account.

On our marketplace, we charge a fixed amount each month, and then the seller (aka. the "Destination") will pay any fees.

Currently, when we use destination parameter, we, as the Platform, gets the Stripe payment fee. We could put the stripe fee in the application_fee parameter, but as these vary by country and card, it is not a easy solution and requires a lot of overhead.

[Remi J.]

Hey Mattias,

If you want the connected account to pay Stripe's fees, the best solution is usually to charge directly on the account instead of using the `destination` parameter. This is covered in details in our documentation here: https://stripe.com/docs/connect/payments-fees#charging-directly

It's definitely a bit different from the `destination` charges and if you use saved customers in the platform you'll first have to create a brand new token using Shared Customers as explained here: https://stripe.com/docs/connect/shared-customers

Let me know if you have any other questions!

Remi

--
You received this message because you are subscribed to the Google Groups "Stripe API Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss...@lists.stripe.com.
To post to this group, send email to api-d...@lists.stripe.com.
Visit this group at https://groups.google.com/a/lists.stripe.com/group/api-discuss/.

[Mattias Fjellvang]

Thanks for your promt and good answer. 

I have an issue with your solution, when trying to charge directly on the connected account, instead of using destination parameter, it says: "Requests made on behalf of a connected account must use card tokens from Stripe.js, but card details were directly provided.".

I am using Spreedly to handle the Stripe integration btw.

[Matthew Arkin]

For PCI compliance reasons connect accounts should use Tokens, if you email support.stripe.com/email they may be able to figure out the compliance aspects between you, Spreedly and Stripe to get everything sorted out.

Sent from Outlook Mobile

[Colin Sidoti]

I'd be interested to learn if Stripe is able to relax this requirement.  I've always found it a bit peculiar since the differences between charging Directly or as a Platform deal more with your fine print, and less with the user experience you offer.

That said, depending on your setup, Spreedly does support "third party tokens," which allow you to create tokens in Stripe.js and pass those to Spreedly.  The caveat is that the payment method you create on Spreedly will only work for Stripe, which may negate your reason for using Spreedly:

https://docs.spreedly.com/reference/api/v1/#create-third-party-token

If your card data is already stored in Spreedly and you need to move it to Stripe, another option is moving the card data to a customer on your platform account, then "sharing" the customer with a connected account to charge directly.

Unfortunately, this is a bit of a headache with the default operations, but it would look like this:

  1. Create an empty Customer on your Stripe account, grab the cus_id: 

      https://stripe.com/docs/api#create_customer

  2. Use the Spreedly "store" method to attribute payment details to that customer.  You must specify the cus_id from step 1:

      https://docs.spreedly.com/payment-gateways/stripe/#stripe-customer-id

  3. Follow the "sharing customers" guidelines from Stripe:

      https://stripe.com/docs/connect/shared-customers

That's 3 calls just to move the card data, and after that you need another to make the charge.

If you do go this route, I'd recommend working with Spreedly to eliminate Step 1.  They should be able to return a cus_id in their "store" call, or allow you to create a "receiver" which would allow you to grab the cus_id in the raw response from Stripe.

Colin

[Matthew Arkin]

The differences between charging directly and charging through the platform have a lot of fine print and nuances, you can get similar user experiences with both, the difference has to ultimately to do with who should be considered the merchant for the transaction, which ends up having a bit of legal and compliance implications.

When you charge directly, it's the connected account that is acting as the merchant, which (I believe, feel free anyone to correct me) transforms your platform from just a platform to a Payment Application, which puts you in scope for the PA-DSS which is seperate from PCI which is why Stripe requires tokens be used. 

If you have all the PCI / PA paperwork set up, then I'd say it couldn't hurt emailing Stripe support and they may be able to get your account set up to use card data with connected accounts / come up with a work around (given the public nature of this thread I don't want to share the work around that instantly comes to my mind), or may be work with Spreedly and come up with a decent solution.

Matt Arkin

https://commencepayments.com

[Colin Sidoti]

Ahhh, that makes sense.

Please report back if you're able to get this requirement relaxed.  I'd hope that Stripe can accommodate card data coming in from vaults which operate similarly to Stripe.js, but I can also imagine that being a rabbit hole of compliance concerns.

Colin

[Remi J.]

Hey everyone,

Jumping in here since I work for Stripe. I can confirm we can relax this requirement once we get proof of PCI compliance. If you rely on Spreedly specifically, then we know they are PCI compliant on their end and can enable the feature on your account. The best solution is to contact us from our support form to discuss this: https://support.stripe.com/email

All the best,

Remi