Refunds being stored in their own separate table or rows?

[nickjj]

I was playing around with Pay using the fake processor and I noticed that (1) pay_charges row will be created in the DB for transactions that include both a payment and refund. If you partially refund a payment 3 times, you still end up with (1) row where the amount_refunded continues to increase.

I kind of anticipated having separate rows for payments and refunds but maybe I'm overthinking things? My use case was thinking it would be nice to know the date of when each refund happened on a payment and we can't definitively depend on reading the updated_at time of the charge to get that information. There's also maybe the application fee being adjusted on a per refund basis (partial)?

But if there were a row for each refund then we would have the complete information about each individual refund and then you could also query a charge to get it along with any optional refunds. This would potentially match what Stripe provides you when you export payments in CSV format. There's individual rows for Paid and Refunded.

I didn't configure the Stripe payment provider yet in this gem, perhaps it saves a list of refunds as data in the single charge row? I would have tested this but it wasn't super clear on how to get this gem to work with Stripe Elements for 1 off charges.

[excid3]

Each payment processor works differently, so that's probably getting pretty nuanced to a single processor?

You can always add that functionality with your own webhook listeners too if you wanted a separate refund table.

If it's important enough, we could add another model. Each one we add makes it harder to maintain and the intention of Pay is to keep things as simple as we can.

[nickjj]

Each payment processor works differently, so that's probably getting pretty nuanced to a single processor?

I kind of see it as being transaction related across all providers that support the idea of refunds, like double entry book keeping except in this case it doesn't need to always equal $0, but it's an idea that:

• User A purchases item for $50
• User A partially refunds item for $20
• User A partially refunds item for $30

Would be an audit log of events associated to the original purchase.

I was thinking this info could be useful to provide to a user in the form of an invoice.

Like let's say someone purchases your Stripe course and you partially refund them $20 for whatever reason. It would be really nice to be able to render an invoice from your local DB where both the initial charge and refund become separate line items with dates, etc.. This way they could use that invoice when calculating their business write offs for taxes. Technically you could make a case that the date of the refund isn't important for that but to display an accurate UI to a user that they're using for official taxes, having the date is handy to boost confidence.

You can always add that functionality with your own webhook listeners too if you wanted a separate refund table.

In this case Pay will also write the refund amount to the pay_charges table too right?

If it's important enough, we could add another model.

It might be doable without a new model, just a new column on the existing Charge or Subscription models. One that shows the status of the payment which could be Paid, Refunded, or whatever makes sense. It would be indexed but not unique. The idea would be that a charge and refund would be added as 2 separate rows, each with a different status.

[excid3]

If you don't need this information often, it can be retrieved with a quick API call which might be Good Enough™?

It's hard to draw a line on what belongs in Pay. Each feature added needs to work for all the payment processors, ideally. Adding this means introducing a model, webhooks for 3 payment processors, and the biggest burden which is maintenance of keeping those up-to-date.

[nickjj]

Which model would need to be added? Is the column approach on Charge or Subscription not going to work? I might have edited my message to add that afterwards if you replied by email which didn't include that bit.

There is a line sure, I was just offering feedback on something that made me think because I just spent ~7 hours reconciling a bunch of CSVs from Stripe and PayPal to a third party tool that had its own CSV exports and the only thing that saved me from being able to detect an off 1 by issue was having payments and refunds being separated out.

When cross referencing your books for tax purposes it's very beneficial to have as much help as you can get to ensure things line up.

[excid3]

I implemented this for Stripe in cd09ed7 🎉

Braintree, Paddle, etc will probably not receive this functionality.

[nickjj]

Excellent thanks. When you say Braintree does that include not doing this for PayPal refunds?