Differences from PGAPI?

Pay is both older - and newer! It has been in the works since 2006, but only the latest revision is really worth using. It has been a challenge to figure out the best place for a payment module to come into the transaction.

If the payment module "knows too much" about the transaction (e.g. product quantities, invoice line items or other amounts), then it's no longer a payment module - it's a shopping cart! And it comes with all of the extra complexity that a shopping cart comes with, even though you may not need that at all.

On the flip-side, if a payment module "knows too little", then it's really just a yes-or-no engine for payments. This is still useful, because any

In the middle of the spectrum, pay expects to know:

1. Where the payment is coming from (AKA which pay_form handler, be it a donation, shopping cart transaction, registration form, etc.)
2. How much was committed and by whom (pay_transaction - including who committed, which form they committed to, when, how much, how much they've actually paid, etc.)
3. A history of payment activities applied against that transaction (pay_activity entries, including pay_method, date, status, total amount applied, etc.)

This is much less complex than any cart system, which also includes the process of deciding how much the transaction should be, which items it's for, and whether they're available. In a perfect world such a cart system would make these decisions and 'hand off' a pay_transaction to pay for the rest of the workflow.

It's also much more complex than PGAPI, which only stores one running list of payment attempts and whether they're successful. It is the job of the developer using PGAPI to write all of the business logic that surrounds the rest of that transaction. PGAPI's approach in this regard is a logical one, because you can do anything you want with its yea/nay responses.

However, in my opinion, there's a lot of duplication in what you want to do with a payment status. By tracking all payments, "no matter what for", in one place, you can:

• Maintain a single set of backends for any type of payment transaction, including those with separate authorization/capture routines (because you're keeping track of whether a transaction has been 'paid up'). Instead of a developer having to decide which of the myriad of ecommerce systems with incompatible feature sets to work with, efforts can be combined and users can use the commerce tools that make the most sense for their needs.
• Maintain an overall history of "how much has been paid over time", no matter what for. This is useful for efficacy tracking, etc. It has support for Views, and anything that extends this reporting will incorporate all transactions that use it.
• Maintain a single record of transactions, in a single format, with enough data to be interoperable with other systems - want to extend it to store your data in Quickbooks? Write that functionality against Pay and you'll have it for any type of donations, sales, cart orders, event registrations, tipjar contributions, etc.
• Install 'something simple' for the short term (perhaps you have only 1 product for sale), and, assuming there's a cart system out there that supports Pay, upgrade to the superior solution later.