Connect: Saving a customer under a stripe account then app.

[Charles Zhang]

Hello,

We are trying to implement a Connect app that's part single account recurring payment utility and part marketplace. What we hope to do is.

1. Create a customer and save it under a stripe user's account.

2. Later on, create a shared customer under the connect app based on the saved customer in #1.

It is similar to the steps here https://stripe.com/docs/connect/shared-customers but backwards.

The reason we may want it backward is there is too much overhead to

1. Check if this customer and card is saved before. (dedup)

2. Save the customer under the app.

3. Call the api to generate another token

4. Charge the card.

5. Save the the card under the stripe user.

Any insights or tips would be greatly appreciated.

[Jim Danz]

Hi Charles,

Unfortunately, that is not currently possible with our flow.
When you are a connect app with r/w access to a merchant, you have
full API access permissions on your connected merchant, but you do not
have permission to copy credit card details *from* the connect
merchant's account back to your connect app account.

Strictly speaking, a reason for this is that your connected merchant
may have gotten those credit card details from some means other than
using your app. So you shouldn't be able to charge a customer under
your connect application account when that customer might not have
been "yours" to begin with. Another way to put it is just that we
don't semantically track "customer X on merchant Y was actually
created by application Z" in a way that would allow application Z to
have permission to copy over customer X from merchant Y.

If I understand what you mean by the need to de-dupe, one possible
flow would be::
1) Create customer on connect app account (no deduping)
2) Use connect shared customers to copy token over to connected merchant.
3) Now you can do the de-dup (fingerprint check) on connected
merchant. If it's a dup, delete the customer that you created in (1).

Sorry that we don't support what you're looking for more directly here
-- happy to answer any followup questions or help consider other
flows.
Jim

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

[DJ Far]

I want to do a similar thing: we have a membership community, all with Connect Managed Accounts on our platform.

I understand the problem using an account's credit card, but what about using the bank object?  All our connected accounts have bank account objects - we want to charge one member a referral fee and pay it to another connected account.

So what I'd like to do is:

1. get the connected account of the payee,
2. get the connected account of the payer,
3. create a bank token from the payer's bank account,
4. create a charge using the bank token, paying to the payee's connected account.

It looked like we could do this if we could create a saved customer from every connected account.

The other option it to retrieve the bank object from the payers connected account and create the token with that

but AFAIK, the bank object returned has the routing number but not the account number?

Any way to do what I'm trying to do?

Thanks,

DJ

[Jieren Chen]

DJ,

Unfortunately, the only way to do this is by creating a separate customer object. I don't believe there's anything preventing you from creating two tokens when the user submits the bank account information. You can then add one token as an external account to the managed account [0] and create a customer using the other token as a source [1].

[0] https://stripe.com/docs/connect/bank-transfers#bank-accounts

[1] https://stripe.com/docs/ach#manually-collecting-and-verifying-bank-accounts

[DJ Far]

Jieren,

That's what I gathered from the docs and from some responses on freenode.

I'm going to try this out and test a charge and see if it works.

Thanks very much,

DJ

To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss+unsubscribe@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/.

[Vincent Chen]

Hi,

Can you explain how we can do de-duplication on the newly created "shared customer"? Let say the owner has seen the customer before, so technically there should be a "shared customer" created. Should store all "shared customers" in a database, and check if the customer-merchant pair exists in the database?

What do you mean by de-duping with the fingerprint on the "connected merchant" account? Let's say I have the "shared customer's" fingerprint, can I go check via some api to see if the connect account has seen this fingerprint in the past?

[Remi J.]

Hello Vincent,

We don't have an API for this at the moment unfortunately and the logic has to live on your end instead. The idea is that you would keep track of the fingerprints for all the cards in your own database. This way you can easily check if you have seen that card in the platform before or not and react accordingly.

Separately, whenever you use Shared Customers and store a card on a new customer on a connected account, you would also keep track of this in your own database. The idea is to map a given customer and card in the platform to a customer and card in the connected account. That way you will be able to always know which account have a copy of a given customer from your platform to keep them in sync.

Hope this helps!

Remi

To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss+unsubscribe@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/.

[Vincent Chen]

Thank you for the explanation! I have a more detailed question here and I would love your advice.

I have a platform application for owners to rent out their things either via one-time transactions or recurring subscriptions. Every owner has a Connect account created for them. The renters have regular stripe customer ids. However, to rent property, we might need to create a shared customer object for each renter/owner pair that has not seen each other before. 

To keep track of who has seen whom, do we need to create a table to store the shared customer ids for a renter and owner pair? If we need to create a database for this, what do you suggest we store to keep track of the interactions? For one-time transactions, do we also need to create shared customers if we do a Destination Charge?

Also, let say after a one-time transaction, the renter decides to rent the item recurrently via a subscription, we definitely want to create and store the shared customer id in a table right? So we still need to do this. Let me know if you have suggestions.

Thank you,

Vincent

To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss...@lists.stripe.com.

[Remi J.]

Hello Vincent,

In your case, each owner has its own Stripe account so that they can receive funds. Then each renter needs to be a Customer with an active card so that you can charge them for a rental fee. You could definitely collect the card details of each owner to create a customer for them in case they rent something in the future though it might be better to do that only once they try to rent. This would avoid having to ask them for card details when they don't plan to pay for anything.

For the renter, the Customer object would live in the platform. This lets you share it directly with any owner based on what they decide to rent. You don't have to keep track of pairs of customers in that case. You have one Customer, likely with one Card and then whenever they do a one-off rental, you create a new token via the Shared Customer approach and you charge them for the fee on the connected account. This adds the benefit that the owner can not charge that card again manually in their dashboard since there's no Customer created. As the platform, you control what can be charged.

The only case you would need a Customer object in the connected account is when a renter wants to rent something for a certain duration. In that case, you have to use the new token to create a Customer on the connected account so that you can put them on a Subscription. When you do this, you would need to keep a mapping of that new customer id on that owner's account to the original customer in the platform.

I hope this makes it a bit clearer!

Remi

To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss+unsubscribe@lists.stripe.com.

[Vincent Chen]

For the last case, we talked about, which is a renter renting something recurringly(i.e. via monthly subscriptions), we would keep database storing the "customer" "connect account" pair, as well as the newly created "Shared Customer" right? This table would have 3 fields for each entry: customer_id, connect_account_id, shared_customer_id?

The Destination charge method for one-time transaction also requires us to create the "shared customer" object first right? So we will still have to store that "shared customer" object when doing a destination charge?

Thanks,

Vincent

[Remi J.]

For the last case, we talked about, which is a renter renting something recurringly(i.e. via monthly subscriptions), we would keep database storing the "customer" "connect account" pair, as well as the newly created "Shared Customer" right? This table would have 3 fields for each entry: customer_id, connect_account_id, shared_customer_id?

Yes the table sounds like the right approach. At least that's how I would build this.

 

The Destination charge method for one-time transaction also requires us to create the "shared customer" object first right? So we will still have to store that "shared customer" object when doing a destination charge?

The Shared Customer approach is only required if you use Direct Charges [1]. If you use Destination charges [2], the charge happens in the platform. That charge can use the platform customer directly in that case and there is no need to use Shared Customers.

So ultimately it seems you only need Shared Customers for a subscription on the connected account. Another approach would be to build the recurring logic instead and each week/month create a destination charge to avoid having to use Shared Customers altogether.

[1] https://stripe.com/docs/connect/direct-charges 

[2] https://stripe.com/docs/connect/destination-charges

Thanks,

Vincent

Remi

To unsubscribe from this group and stop receiving emails from it, send an email to api-discuss+unsubscribe@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/.

--
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+unsubscribe@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/.

--
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+unsubscribe@lists.stripe.com.