Peter, some notes:
There are a ton of different ways the payment gateways interface to commerce apps. Some examples:
- Straightforward API calls through HTTPS GETs or POSTs typically with authorize, capture and cancel calls.
- A form is displayed whose action attribute is a URL located on the gateway interface. After verification, user is redirected back to the originating site, which has to make a separate API call for capture.
- Same as above, but the server makes a request to originating server to confirm that the payment is valid.
The first method is widely available in the US. It's a bit expensive when implemented in Denmark because it requires special certification from PBS.
For recurring payments, you need special permission (at least in Denmark) to store credit card information, but this is not hard to get if you follow the security requirements. When you're doing an interactive transaction the user should be required to enter the 3-digit CVC code. This code must not be stored, so a subsequent recurring billing is code without CVC (which is always possible if the application requests it).
Subscriptions require some bits of policy to be set. For example, when does renewal occur? On the first day of each month or 30 days after the subscription started? If it occurs on the first day of a month, how much does the subscriber pay for the "first month" which may be shorter than 30 days? If it occurs 30 days after subscription started, what happens when the user upgrades the subscription in the middle of a subscription period? Plus, what happens when the site decides to change any of these choices?
