#Steffen
tawny oracle
Yes but after you detached it, you wouldn't be able to use it anymore. Also we generally advise against floating unattached payment methods. I remember it could be some time-limit but be sure to test it out in Test mode
fickle osprey
Thanks. With the detachment I did read in the and that is fine for me.
I was also thinking on how to test it in test mode, but it can be that the paymentmethod would be floating for a couple of month until being used.
Maybe in general, you have a recommendation which stripe tools and mechanism I shall better use for my use case? In my case it is for cancellation fees which can occur in somepoint in the future
tawny oracle
I think the bottle neck here is you don't want to store the customer visible in Stripe Dashboard. What does it have anything to do with cancellation fee? You can still have the customer and the payment method attached to it, without any sensitive information if you aren't prefer to
Just a Customer object, with its Id, and attached payment method id
fickle osprey
Right, but I store that info in the connect account of my customer to which I provide stripe as a service. But as the customer has a standard account, my customer could go into the Customer List and just issue a payment whenever he wants
fiery bluffBOT
steady isle
Hey! Taking over for my colleague. Let me catch up.
Could you please rephrase/summariez what was the exact limitation on your integration ?
fickle osprey
I would like to offer cancellation fees to my customers via stripe. During the booking process of a guest, he specifies his payment method, which my customer can then debit in case of no-show or cancellation. My customer is connected via a standard stripe connected account, i.e. he has access to a fully functional dashboard.
If I now create the guest who makes the booking as a customer with his payment method in Stripe, then my customer sees this guest yes. Theoretically, my customer could now go and charge the specified payment method regardless of a cancellation of the guest. I would like to avoid this but still have the possibility to offer my customer the possibility to debit the then specified payment method with the agreed amount in case of a cancellation.
steady isle
Why your guest/customers are Connected Accounts ?
fickle osprey
So that the responsibility for paying and dealing with disputes etc is not our, but our customers responsibility.
Also we are planning on offering them to sell stripe-products via our app and wanted them to manage products, tax, invoices etc via their own stripe account
That being that both use cases could also be separated accounts.
also they are connected accounts because if they issue a fee to their guests, the fee is automatically send to them (our customer account) and not to us (in which case we would also need tom forward the payment)
steady isle
So you are using Direct Charges here, and the guests are client to your Connected Account and not your Stripe Platform Account ?
fickle osprey
Guests are client to the connected account, correct. Yes we are using Direct Charges. (We are creating payment intents and provide the connected account id)
steady isle
I would like to offer cancellation fees to my customers via stripe.
So what is the issue here exactly ?
fickle osprey
My customer has access to a Stripe dashboard of his connected account and to the customer list. If I now store the payment method of the guest together with a customer entry in Stripe in the Connected account in order to debit it later when needed to charge cancellation fees (this will be done via my system in case of a cancellation)
So my customer can see this payment information in his Stripe account at any time and can debit the payment method improperly at any time! Even in a case where there was no cancellation. I see a bug risk for abuse potential here why I wanted to work with floating payment methods
steady isle
That how you designed your integration. If you don't want to let your connect customer to have full control o their Stripe Dashabord, then you need to update your integration to use Customer or Express Accounts
But unfortunately you can't limit the usage for some cases and not for others
fickle osprey
Yes. But then I would need to deal with things like disputes and rejections myself and not my customers 😦
Which brings me back to my original questions. Do you know about any expirey or time limitation on floating payment methods or floating (successful) Setup Intents? Or maybe have an advice on how to test that?
steady isle
Yes. But then I would need to deal with things like disputes and rejections myself and not my customers 😦
Yes if you want to not let your connect account to charge their customer on their own
Do you know about any expirey or time limitation on floating payment methods or floating (successful) Setup Intents? Or maybe have an advice on how to test that?
You shouldn't make floating payment methods. If you detach a payment method then you should delete it or not reuse later
fickle osprey
I would want to wait for attaching it until the actual payment. So I keep the reference for the payment method (the id) in my system and when it comes to charging, create the customer, attach it charge, detach and delete the paymentmethod
steady isle
When collecting a PyamentMethod you need to attach it to a customer
what you are trying to do is a workaround, it's like a design leak in your system
If you want to have more control on your connected Account then you shouldn't be using Standard Account
fickle osprey
okay understood.
Any issue if my customers would have 1 Extress Account for Cancellation Fees and 1 Standard Account for selling stripe-products via our system?
steady isle
For the same customer, you mean creating too connected accounts ?
fickle osprey
Yes. We would have Express to prevent access to payment methods and then another one which they use and have more access
to sell bookings via "stripe products" on our platform
steady isle
No I don't think that's a good approach honestly
However if you mean there is two different website/businesses are involved here
fickle osprey
Yeah... I mean the only thing I am trying to achieve is preventing abuse of payment methods
steady isle
in that case yes you can create multiple accounts... one for each website/business
fickle osprey
Guest provide their payment method just in case of a no show or late cancellation. But my customer would always have access to that payment method for anything and any payment they would want to issue
If I will only have 1 account ( standard account )
fickle osprey
A single one. We are a booking system for restaurants. And we want allow no show fees (for which an express account would be best;less control) and also allow our customers to sell their events (for which a standard account would be good, because customers manage stripe-products (events) on their own) via our reservation system.
steady isle
In that case I think you should reconsider using a single Connect Accoun
I think Express account is a good option for use
using Destination charges
fickle osprey
Okay. So for our second case that customer sell their products via our platform we then we then need to implement stripe product management via our App? Or is their a way for Express Account users to login and manage stripe products via the Stripe Dashboard UI?
steady isle
Okay. So for our second case that customer sell their products via our platform we then we then need to implement stripe product management via our App
Earlier you said that your connect accounts can sell product on your platform, how these products will be managed if they are sell on your platform ?
fickle osprey
The Intention was to let customer manage them via the stripe dashboard (that is why I prefer standard connect account). This way they can configure products using your UI and also configure everything else like taxes, invoices correctly and we do not need to replicate all that functionality in our system via your API
steady isle
Are you planning to get fees from the Standard Account ?
Or you are giving the service for free ?
fickle osprey
The service is free
steady isle
Then why you use Connect Accounts ?
fickle osprey
So whatever our customer charge their guests is then re-directed to their account and their pocket
Otherwise we would receive the payments on our account and then need to payout our customers. That is lot of admin effort.
Also, it creates a relationship for the payment between us and the guest of our customers. Otherwise the relation of the payment would directly be Guest to our Customer
steady isle
Also, it creates a relationship for the payment between us and the guest of our customers.
The way you are designing your integration, I don't see a link/relationship between the payment you connect accounts/customers and your platform
Your Standard accounts are 100% indepedant to your Platform Account
fickle osprey
I dont mean a link in a technical way, but in a "business relationship"
Guests to reserve at our customers. Guests do puchase Events at our customers. Guests are charged cancellation fess by our Customers
steady isle
No even as a business relationship there is no link.
Your connect account are 100% independant from your Platofmr Account.
steady isle
For example if there were a connection (even business) you should be using Stripe header in order to create products and Payment
steady isle
But it allows us API access into their account.
Just for listing
but you are not doing any changes.
fickle osprey
Yes that is what we do, using the stripe header
steady isle
You are using the Connect Auth Header for listing objects I imagine
fickle osprey
Yes
steady isle
but the payment are done on the Connect Account side by them selves
fickle osprey
And for creating PaymentMethod, SetupIntents etc
steady isle
you have no control on it
Ok in that case you need to change and use other connect Accounts
like Express/Custom if you want to have more control.
And you should be using only 1 type for each Connect Account.
fickle osprey
Yeah okay, understood
Would Custom Account allow me to control some permissions ? LIke issuing charges from the UI?
fiery bluffBOT
steady isle
Custom Account doesn't have access to Stripe Dashboard.
fickle osprey
ah okay I see
hm well. So the only way I can build what I want is to use express account and replicate the whole "stripe product" management in our application I guess
Or I use standard accounts and trust my customer not to abuse their guests payment methods that are only meant for no shows and cancellations
steady isle
Yes exactly!