ATHENA-Payments keeping a record of transactions

[Gary Moore]

Should ATHENA-Payments keep records of transactions, statuses, etc? My thought is no, we're acting as a gateway and that is that. The ultimate processor the payment (Braintree, Authroize.net) keeps records, will act as the system of record for payment transaction information, and Clients will go to them to have their billing and revenue questions answered.

Is that reasonable? Have we forgotten a use case or two?

Gary

[Ryan Price]

What about detailed reporting tailored to our vertical (theatre/arts)?
Try to track things across certain campaigns like the "under 30
outreach campaign", or is that the client's job?

Peace,
Ryan Price
DrupalEasy.com
rpr...@ryanpricemedia.com
@liberatr
407-484-8528

> --
> Visit: http://athena.fracturedatlas.org/tix
> Fork: http://github.com/fracturedatlas
> Chat: ##athena on Freenode
>
> You received this email because you are subscribed to the "ATHENA
> Tix Developers" group on Google Groups.
>
> To post, email: athena-t...@googlegroups.com
> To unsubscribe, email: athena-tix-dev...@googlegroups.com
> For more, visit: http://groups.google.com/group/athena-tix-devel?hl=en

[Tim Thomas]

I would say you absolutely want to keep a record (although no credit
card info). It's essential for trying to trace back where something
went wrong. I basically create pending transactions with a unique id,
shoot them over to the payment gateway and then update them on
transaction completion.

You'll need it for reconciliation reporting as well.

> --
> Visit: http://athena.fracturedatlas.org/tix
> Fork: http://github.com/fracturedatlas
> Chat: ##athena on Freenode
>
> You received this email because you are subscribed to the "ATHENA Tix Developers" group on Google Groups.
>
> To post, email: athena-t...@googlegroups.com
> To unsubscribe, email: athena-tix-dev...@googlegroups.com
> For more, visit: http://groups.google.com/group/athena-tix-devel?hl=en
>

--
Tim Thomas
Founder/Lead Developer
BuyPlayTix.com

[Joe Winter]

"Should ATHENA-Payments keep records of transactions, statuses, etc?"

Sorry for my ignorance here. What's included in the "etc" part of that?

I feel like the question should be, "If ATHENA keeps transaction records, what data would be necessary to keep?" What's the end goal, here? Reporting?

Also, what level of integration should there be between ATHENA and a gateway? Or are we assuming that will happen somewhere closer to the interface layer?

[Adam Huttler]

At an absolute minimum we need to store whatever info might be needed to process a refund.

In general, though, I like to err on the side of storing more rather than less. I've had a dozen or more experiences over the years where an unanticipated use case required major refactoring because I wasn't storing enough data.

The obvious exception would be something like a complete credit card number, because of the security risks. Beyond that, there's very little downside to storing more rather than less.

[Justin Karr]

Obviously we need to do what we need to do for PCI compliance and we'll
leave it to Gary and team to sort that out.

In general I agree with Adam that more data is better. However, our
intention isn't to use Payments as a source for any kind of reporting (to
Ryan's point).

We currently have five top level data sources (or core components, as we
call them): Tix, Orders, People, Actions, Notes. We believe that
more-or-less any conceivable report can be run off of these.

/Tix: Tickets

/Orders: Orders to Buy Things (generally tickets) or Make Donations.

/People: People making Orders and using Tickets (and people we'd like to
someday make Orders and use Tickets).

/Actions: Things people have done ("Joe bought a ticket", "Tim called Ryan
to solicit a donation")

/Notes: Our catch-all that lets us associate arbitrary information with
anything (and full-text search it).

In a theoretical implementation, reports around the "under 30" outreach
campaign would be pulled from a combination of People, Actions and Orders.

(Note, query strings are _totally_ speculative.)

Report 1: From People - Potential Patrons under 30
... /People/?age<30

Report 2: From Actions - Potential Patrons under 30 we included in the
"under 30" email blast.
... /Actions/?campaign="Under 30 2010"&communication="eblast"

Report 3: From Orders - Potential Patrons under 30 who bought tickets
during a period.
... /Orders/?campaign="Under 30
2010"&purchase_date>"1/1/2010"&purchase_date<"12/31/2010"

Or, if we implement this in a helper component - say something called
CampaignReportHelper - we could do something like:

... /CampaignReportHelper/?campaign="Under 30 2010"&report="purchases"

Justin