#david2 - Refund request
sage stone
Credit notes are not related to charges per se. So there's no application fee to be returned.
Application fees are a feature of Connect and Platforms charging fees for connected accounts
unique ivy
i am working on an app that is using the connect platform, and does collect application fees
to issue a refund on a charge there, is it not sufficient to create only a credit note request?
(issue a refund and refund app fees to the connected account)
sage stone
In that case you create refunds. Credit notes are related to invoices
We specify that here: https://stripe.com/docs/connect/destination-charges#issuing-refunds
unique ivy
ok and then I can create a credit note that explicitly references that refund I take it
sage stone
If you want to refund funds to a customer and refund application fees to a connected account, you only need to create the Refund object with return_application_fee set to true. Credit notes are entirely different things.
unique ivy
the app I'm working on deals exclusively with credit notes, all sorts of tables and logic dedicated to processing credit notes, but they want to begin refunding application fees, so I'm trying to figure out the impedance mismatch; seems like the thing to do is to issue a refund, wait for it to come back, then create a credit note from that, is that a not-incorrect use of credit notes?
sage stone
What are the credit notes for? We create credit notes in Stripe that tie back to invoices, as you see here:
https://stripe.com/docs/invoicing/integration/programmatic-credit-notes
unique ivy
Use the Invoicing API to adjust or refund finalized invoices with credit notes
^^^^^^
I think we're relying on creating credit notes to effectively create refunds
sage stone
So you are creating invoices, correct?
unique ivy
yes there are invoices, on which we are collecting application fees
sage stone
And are these invoices paid or open?
unique ivy
they are paid
sage stone
Testing some stuff out on my end
I'm still trying out a couple things but the flow that's taking shape is what you described earlier. You create the refund, include the application fees, and then reference the refund when creating the credit note.
https://stripe.com/docs/api/credit_notes/create#create_credit_note-refund
hybrid tusk
(<--- the person who implemented all this a year ago according to suggestions made by Stripe folks ion IRC) The scenario here is that we have invoices which have line items that may represent multiple 'things' related to our application. We have historically used paymentIntents for everything but we are migrating our architecture to use Stripe invoices for everything via the API only. When we built out our 'refund an invoice' functionality, it was entirely around credit notes. I don't recall that there was any way to refund an invoice effectively a year ago besides this -- what exactly is a 'credit note linked to a refund'?
hybrid tusk
I understand that a credit note can be issued on an invoice absent a payment, so it's semantically not the same as a refund
trying to determine if we misunderstood something a year ago or if something has changed such that we were monkeying with credit notes in a way we should not have been
It looks like we used credit notes because we needed a refund mechanism that applied to individual line items rather than to the charge overall; we had to track where the refund 'came from'
and credit notes on paid invoices create a refund
sage stone
You are correct, a credit note has more options but you can process the refund first, and then explicitly link the credit note to that refund object
Which is the API parameter I linked to above
hybrid tusk
that introduces more failure points, though, in that it's two actions from us to do one 'thing' versus 'dear Stripe, please issue this credit note and you can do the refund business, xoxo us' -- it seems like it'd be less complicated to be able to supply one or more parameters about the refund you want created to the credit note create endpoint
changing the whole workflow of refund/creditNote just to flip refund_application_fee seems like the tail wagging the dog
Refunds only have refund_application_fee and reverse_transfer - surely these could be relayed through the 'create credit note' endpoint?
sage stone
How would the API know what portion of the application fee to refund if the credit note is only for one out of several lines? The complexity here is more significant due to where the fees are applied and what can be credited. For this reason we have to leave it up to you how you will handle it.
If you are generating a refund and credit note for a single line in a many line invoice, should we refund the entire fee? A portion?
hybrid tusk
You already solve that problem when creating the refund, though. You do it proportionally. You don't let us decide how much of the app fee to refund when creating a refund -- it's just a boolean value that says okay, this charge was $100 and the application fee was $5, so a refund of $50 will refund $2.50 in application fees. If we want more granular control over the application fees or proportions, we have to use the separate application_fees endpoint(s)
The API artchitecture already allows for two entry points to app fee refunds: one that is simple but insists that everything happen in proportion to the actual charge made (fair); and one that says do whatever you want but you have to deal directly with the app fee ID
I'm just suggesting you let us pass on the value of refund_application_fee as true or false to the refund that is automatically created. It would default to false so it doesn't break anything, and if somebody wants to delve into non-proportional refunds, they're welcome to with the application_fees endpoint
sage stone
I'm not aware of anything on the horizon but I'll check to see if this is being considered.
hybrid tusk
It'd be a nice convenience. I think, rather than creating the refund first and potentially interrupting the flow between refund and credit note (even in the super unlikely use case that our app makes only 1 of the 2 required calls) , what we'd do is just keep doing what we're doing but then flag the transaction on our side for a future call to the application fee refund endpoint. Making the credit note/refund a single, atomic operation is really nice for consistency and the app fee can be cleaned up after the fact. But even less work for us if we can let Stripe do all the heavy lifting. 🙂
sage stone
Alright I have noted your feedback and we will be taking it into consideration for potential feature enhancements.
unique ivy
very helpful, I appreciate the quick responses you guys have here. if you have an "S" by your name are you a slack employee?
gusty terrace
Stripe 🙂 but yes
hybrid tusk
too many 5-letter-S technology shops that run our technology shop. 🙂