Most organizers think in terms of attendees, so it's critical to be able to match attendees with their related financial transactions (even though on the database end we have a couple intermediary models). Here's one real-world use-case (names changed):
Mildred Hopkins accidentally orders two passes when she only means to order one. The Organizer would like to refund one of these passes. Because Dancerfly only supports complete refunds on transactions and this is a partial refund, it will need to be done through Stripe. The Organizer should be able to search the attendee table for Mildred by name and navigate from there to the stripe transaction.
Currently this involves writing down the order code from the attendee table and manually cross-referencing it to the Finances table. Not ideal.
Essentially this would mean linking from the Transactions in the Order detail page to their stripe / dwolla equivalents. That's where I'd want to start with this ticket.
Most organizers think in terms of attendees, so it's critical to be able to match attendees with their related financial transactions (even though on the database end we have a couple intermediary models). Here's one real-world use-case (names changed):
Mildred Hopkins accidentally orders two passes when she only means to order one. The Organizer would like to refund one of these passes. Because Dancerfly only supports complete refunds on transactions and this is a partial refund, it will need to be done through Stripe. The Organizer should be able to search the attendee table for Mildred by name and navigate from there to the stripe transaction.
Currently this involves writing down the order code from the attendee table and manually cross-referencing it to the Finances table. Not ideal.