Payment Gateways

Why are payment gateways such a pain to integrate with? There are only two real models:

1. Merchant site directs the user to the payment gateway site with details of what they are paying for. Confirmation of the transaction is POSTed back.
2. Merchant site collect the data on a secure server, and requests payment via RPC.

So why does every payment gateway have a myriad slight variations? This means developers have to write adapters for each payment gateway, running the risk of introducing various security vulnerabilities in each. But not just that, error handling is at best muddy. I've used systems with non-existent error handling. I've even written systems without error handling (the trick is in the wording; you have to avoid saying "Thank you for your payment" and instead say "You will receive confirmation of your payment by email." This architecture is not my design, I hasten to add).

Strangely, these variations on a theme seem to have a single meme for the documentation: to split it between at least two PDFs. These PDFs are usually along the lines of "Integration Notes" and "Advanced Integration Notes", although if both of the above models are supported there could be one or two more. I haven't the faintest idea why these people think that PDF documentation is better than HTML.Which is what the rest of the world uses.

The payment gateways should put their heads together and come up with a standard. Two protocols. So that with a single library, you would be able to use whatever payment gateway you want, without having to maintain dozens of adapters. This could also take the time to remove paranoid "security" checks, like verifying HTTP Referer headers (which is nonsense), and they could codify how to make Payment Gateway pages look less rubbish (because they always do).