negative10xprogrammer

[vague pawn]

the problem with the latter is, Im not sure what to set as the idempotent key.

[toxic hearth]

If you use automatic payouts, you can review the payments associated with each payout retroactively. But if you have your own logic and want to do manual payouts, then you need to keep track of that in your own system, yes.

How does idempotency relate to this, exactly?

[vague pawn]

nvm the idempotency key is not the problem, the problem is..

how can I make sure the user doesn't withdraw the same amount multiple times? yes, sure, I set the "escrow" entity as released and persist that in the db upon success, but what if there's a failure and it's not persisted

then they could technically withdraw that same amount again

but what you're saying is... i should aggregate the sum and make one payout (if it's multiple purchases to be paid out)?

instead of making multiple separate payouts in a loop?

that's mainly what im asking i think, multiple payouts vs one aggregated payout

[toxic hearth]

That's really up to you to decide how to handle things

[vague pawn]

actually the correct terminology here is not payout, it's indeed a transfer but i have automatic payouts

[toxic hearth]

But I would probably group the payouts into a single payments

[vague pawn]

but i've named it payout in my system due to auytomatic payouts

[toxic hearth]

Ok well now thats different

How are you collecting payments and transferring?

Can you explain your payment flow / hare an example payments and/or transfer?

[vague pawn]

payments are collected with payment intents (or setup intents) - then they stay in our stripe account until scheduled to be transferred to teh host, upon which the payout should from there be automatic

so the host doesnt need to interact with stripe

customer pays with card/klarna > we receive the funds > we hold it until scheduled to be transfered to the hosts stripe account (and from there automatic payout)

[toxic hearth]

You're manually creating transfers separate from the payments?

ie, the flow is like this: https://stripe.com/docs/connect/charges-transfers

[vague pawn]

 public async Task<Result<string>> PayoutToHost(decimal amount, int escrowId, Currency currency, string destinationAcct, long? reservationId = null)
    {
        var options = new TransferCreateOptions
        {
            Amount = ((long)amount * 100),
            Currency = currency.ToString(), // Listing currency
            Destination = destinationAcct
        };

        var requestOptions = new RequestOptions
        {
            IdempotencyKey = escrowId.ToString()
        };

        if (reservationId is not null)
            options.TransferGroup = reservationId.ToString();

        var service = new TransferService();

        var retryPolicy = StripePolicies.TransientAndStripeExceptionRetryPolicy();

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

            return transfer.Id;
        }
        catch (StripeException ex)
        {
            Log.Error(ex, ex.ToString());
            var customStripeErrorMessage = StripeExtensions.GetCustomStripeErrorMessage(ex);

            return new PayoutToHostError(customStripeErrorMessage.Message);
        }
        catch (HttpRequestException ex)
        {
            Log.Error(ex, ex.ToString());

            return new PayoutToHostError();
        }
    }

yes a transfer, from our stripe account to their stripe account

[toxic hearth]

Please don't paste large blocks of code unless its applicable here

[vague pawn]

well this is how i create a transfer

[toxic hearth]

Is there any part of this not doing what you expect?

[vague pawn]

No, it's working fine. But you said it was different with automatic payouts. I'm asking about one large payout vs multiple small, you seem to have answered that already but i thought there was a difference with automatic payouts

to be correct, i am talking about multiple vs one large TRANSFERS n this case

as the payout is set to automatic

but one large trasnfer then I take it

[toxic hearth]

YOu're saying payouts again, but do you mean transfers?

Right

[vague pawn]

yes, we call it payout in our own system haha, but transfer is the correct terminology

[toxic hearth]

If you're manually creating transfers as part of the separate charge & transfer flow, its really up to you and how you wish to track this

[vague pawn]

no payout is done via code on our own

on our end*

[toxic hearth]

Creating one transfer for 10 payments or 10 transfers is just a matter of how you want to track this

[vague pawn]

one transfer seems like less complexity and less failure prone

if one of the transfers fail for some reason or there's a network error on the last 5, suddenly i have to do a bunch more stuff to handle that

sure alright

[toxic hearth]

For you to consider is how you would handle a refund flow and reversing the transfer

Transfers don't fail if the request succeeds

[vague pawn]

these are payouts to a merchant, so i dont think the refund flow applies

[toxic hearth]

Either you'll get an API when creating the transfer, or it will be successful

[vague pawn]

possibly reversing the transfer but i dont see under which circumstances that would be needed

right yes

[toxic hearth]

Ok if its not relevant for your business and payments flow that's fine, just wanted to mention it

[vague pawn]

all we track on our end is how much we owe the host and that's it. if transfer succeeds, we assume stripe handles the payout to external account and can thus mark the "escrow" object as released and thus we owe the host minus that amount now

so i guess then it doesnt really matter if its one or multiple transfers

but multiple transfers = more clarity