#holykent

1 messages · Page 1 of 1 (latest)

sturdy hatchBOT
naive thistle
#

Not sure. Recommend asking support: https://support.stripe.com

Stripe: Help & Support

Find help and support for Stripe. Our support center provides answers on all types of situations, including account information, charges and refunds, and subscriptions information. Get your questions answered and find international support for Stripe.

#

We just help developers use the api in here

velvet ember
#

Ok so im a bit confused about the flow now.

A friend of mine keeps mentioning charges, but I dont have that in my code.

This is an airbnb type system (aspnet core web api) where customers interact with us to book listings from our hosts.

When a user wants to make a reservation, they interact with stripe elements > input card details > stripe reponds with paymentMethodId

this paymentmethodid is used in my bacxkend to create a paymentintent and is instantly confirmed, basically.

This means the money is in our stripe account, right?

And then, after that, I schedule a background job to run 24 hours after the designated check-in-time, this job then creates a TransferCreateOptions and that's that. Now that specified amount wil lbe transfered from our stripe account to the hosts stripe account minus our commission.

And with automatic payout, stripe handles the rest.

isn't this correct? where does charge come into play?

#

im not using stripe checkout, is that why

naive thistle
#

Payment Intents are the newer integration path

#

Charges are the legacy flow

#

PaymentIntents are built on top of charges though, so every payment intent has an underlying charge

velvet ember
#

ok, so is the flow above correct for my use case?

sturdy hatchBOT
naive thistle
#

Yeah

velvet ember
#

and in the case of offline payments, i.e. where the customer decides to pay in person, we still create a payment intent so we can consume it upon reservation cancellation

naive thistle
#

You shouldn't need to create a payment method though

naive thistle
#

Payment Intent is created up front and you collect payment method directly on it

#

A payment method is automatically created for you

velvet ember
#

but if stripe sends me a paymentMethodId, doesn't that mean they already authorized/validated the card from the input in the stripe element?

# 
 public async Task<Result<CreatePaymentDetails>> CreatePayment(decimal amount, Currency currency, string? token)
    {
        var options = new PaymentIntentCreateOptions
        {
            Amount = (long)amount,
            Currency = currency.ToString(), // Listing's currency
            PaymentMethodTypes = new List<string> { StripePaymentMethods.Klarna, StripePaymentMethods.Card, StripePaymentMethods.SepaDebit },
            ConfirmationMethod = "manual",
        };

        // Klarna needs only the client secret so this wont apply to klarna. 
        if (token is not null)
        {
            options.PaymentMethod = token;
        }

        var retryPolicy = StripePolicies.TransientAndStripeExceptionRetryPolicy();
...

I do this

#

we create teh paymentintent manually on the backend

#

so you're saying stripe elements creates the paymentintent and there's no reason for me to do so?

naive thistle
#

No you need to create the payment intent

#

Just look at the doc I sent

#

It outlines what I'm talking about

# 

this paymentmethodid is used in my bacxkend to create a paymentintent and is instantly confirmed, basically.```
#

You said this

#

You shouldn't need to explicitly create the payment METHOD

velvet ember
#

well then, if I decide to confirm that paymentintent 1 month from now, who is being charged if there is nothing attached to it but an amount and a currency?

naive thistle
#

If you don't want to process payment when you collect the payment method they you should be using a setupintent

velvet ember
#

isn't collecting a paymentmethodId and using that to create a paymentintent essentially "the same thing"? is there a reason this is not "allowed?"

It says "do not have long lived setup intents" - but in an airbnb setting you can book months into the future

alpine bluff
#

Hi 👋

I'm stepping in as @naive thistle needs to head out soon

velvet ember
#

Hello there

alpine bluff
#

Then, when you are ready to bill your customer, you can create and confirm a Payment Intent using that saved payment method

naive thistle
#

The issue with creating payment methods directly is they won't be set up for future use

#

Higher liklihood of declines in the future

velvet ember
#

Ah alright, well that sounds reasonable.

About transfers, in this particular case we may have to hold funds for 6 months if the customer makes a reservation 6 months from now and we don't pay out the host until after checkin.

The reason for this is to avoid troll hosts.

Is this

a) possible with stripe? holding the funds this long
b) we schedule a background job to run X amount of time from now (on checkin date) that transfers funds (from our stripe to their stripe connect account) and with automatic payout, stripe handles the rest?

#

Shouyld I even be making these transfers in my own applicatiion with a background job or is there some more convenient and surefire way to handle it via stripe?

alpine bluff
#

Transfers? Just to clarify, are you working with other Connected Accounts?

velvet ember
#

Both paymentintents and payouts, yes.

paymentintents for when the customer makes a reservation, payout to hosts when we payout their part of the payment, which is the total minus our commission

#

think airbnb

#

customer pays us, we hold money until checkin, we pay host total amount minus our commission

alpine bluff
#

Okay and you want to hold funds for a particular period of time prior to transferring funds to avoid bad actors?

velvet ember
#

Yes, precisely. preferrably until after checkin.

#

the current implementation uses hangfire to schedule a job that will create the transfer. With automatic payouts enabled, I was under the impression stripe will handle the rest (i.e. payout to the host's external account as provided in the onboarding flow) and all I have to do is create a successful transfer to destination = hostAccountId

alpine bluff
#

Yes if the host Connected Account is on automatic payouts, they will get funds from their Stripe Account balance deposited in their bank account.

#

For this approach I would recommend the separate charge & transfers charging structure. This separates the timing of the when you collect payment and when you transfer funds to the host Connected Accounts. https://stripe.com/docs/connect/charges-transfers

Creating separate charges and transfers

With Connect, you can make charges on your platform account on behalf of connected accounts, perform transfers separately, and retain funds in the process.

velvet ember
#

I looked at the docs you sent me, and that looks exactly like what I described above?

#

I'm getting tripped up by the terminology though, I can't see a mention of charges in the actual code.

#

the term seems to be transfer, and so I'm confused as to why the word charge is mentioned

#

transfer is stripe to stripe, no?

#
  1. Customer makes reservation
  2. We create and confirm intent in the backend
  3. Upon success (via webhook) we schedule HostPayoutJob to run X time from now (on checkindate)
  4. In this job, we do this
 public async Task<Result<string>> PayoutToHost(decimal amount, Currency currency, string destinationAcct)
    {
        var options = new TransferCreateOptions
        {
            Amount = (long)amount,
            Currency = currency.ToString(), // Listing currency
            Destination = destinationAcct,
        };

        var service = new TransferService();

        var retryPolicy = StripePolicies.TransientAndStripeExceptionRetryPolicy();

        try
        {
            var transfer = await retryPolicy.ExecuteAsync(async () => await service.CreateAsync(options));

            return transfer.Id;
        }
....
#

isn't this essentially what you lniked above? separate charges and transfers?

#

and the only other path in our code is in person payment, where i was advised to use setup intent instead

alpine bluff
#

Charge - collect money from a Customer

#

Transfer - Send money from one Stripe Account to Another

velvet ember
#

so... paymentintent create > payment intent confirm = charge?

And my flow above is basically already doing what's advised in the docs you sent me?

#

and also, do you know how long i can hold money in my own stripe account? the moeny we receive from customers via confirm paymentintent

alpine bluff
#

Yes your flow looks to be what we would expect. As for holding funds in your account, the only concern there is making sure your payouts don't send it all to your bank account before you have a chance to transfer the funds to connected accounts. That is something you manage through your own payout settings.

velvet ember
#

right, you touch on something I haven't considered, that we need to know which money is safe to withdraw to our own external account.

#

thanks

alpine bluff
velvet ember
#

Gotcha.

Also, do all my merchants need a connect account?

I'm not asking if they all need it to get paid, I know they do, but some may be rather averse to signing up for it and I'm not sure if I should let their listings be bookable still. And in that case, we simply track in our applicaiton how much we owe each host, and the day they decide to do the onboarding and supply a bank account, they have an option to just withdraw the money.

Or sdo they legally need an account for stripe to know that they exist in any capacity?

alpine bluff
#

If you want to be able to transfer money to them using Stripe, they need an account

velvet ember
#

And it's fine for their money to pile up in our balance until the day trhey decide theyh want to withdraw (after which they will have to do the onboarding process)?

#

I mean that's on them I guess, if they don't want their money. But still, I could see that being the case in some situations

alpine bluff
#

If you want to wait until they have accumulated funds to onboard them you can take that approach

#

I would make sure to create a transfer_group string to uniquely identify the charges they are associated with though

velvet ember
#

ah ok I did that in my own system, but seems with transfer_group that is not needed

alpine bluff
#

You can do both to be sure, and maybe save the transfer_group to your own system as well for reference

velvet ember
#

in what capacity are they grouped? can i fetch groups via the api? or is it mainly for reconciliation and auditing purposes and is only accessible via the dashboard?

alpine bluff
#

We describe how it is used in the documentation I provided. Let me know what part of that is not clear