Merchant Account 'actions' and resulting returned 'data'

[AffiliateDreamer]

What are the potential set of 'actions' one performs with a merchant account?

I can think of:

Charge
Authorize
Void
Return

What kind of data would be returned from these actions that one would want to store in a database? (i.e. transaction numbers or reference type numbers?)

Does this type of data vary between the various merchants or are they standard?

[rocknbil]

Other "standards" are capture, credit (as in credit to the customer, for a portion of "refund" or return,) and batch settle.

I haven't seen much in common in interfacing with gateways, they all pretty much have their own methods of authenticating the transaction and returning a response. Some common threads:

SSL: most rightly refuse any attempts to post to their servers if not done over a secure connection and simply don't respond, even with silent post.

Authentication: this can be done with a .pem or a form of hashing (MD5, for example, in combination with several other unique items, such as the account ID and the transaction total.) Usually you have a key or .pem file, which is a form of digital certificate, that must be sent to the gateway along with the order in combination with an account ID and sometimes (old school) a password for posting transactions. If the authentication doesn't match what they have on file, the transaction is refused.

Transaction ID: This is indeed an important item, and it varies how it's generated. Some allow you to send your own, some require it to be generated by their servers. For example, you make two posts: one to get the TID and the second to post the transaction with the TID. Some will generate a TID for you if one is not provided. (See CISP storage below)

Typical transaction requirements: "Typical" is a bad word for this as they all differ in how it's used, but there is always a way to use/disable AVS, CVV2, and otherwise use their provided tools for validating the credit card info. Most of them can be quite robust, but use with caution - rejecting orders due to AVS mismatches (billing address does not match card on file) can lose legitimate orders.

CISP Storage: I have been working with one customer's merchant account for a method of CISP (Cardholder Information Security Program) Storage that works for recurrent billing (membership renewal) from the server side without storing the CC info. This is a completely different "kind" of transaction from ordinary transaction post. Here's how this works, and it looks to be an awesome method.

Most CC gateways have recurrent billing methods, but they are all internal, meaning, the provider does the recurrent billing and you have to log into their interface to gather who's been "renewed" and manually update your server database.

With this system,

1. When the original purchase is made, you send a variable that indicates you wish them to store this CC for future purchases/renewals (this gateway is, of course, PCI compliant.) Their system generates a transaction id. You store the transaction id AND only the last four digits of the credit card number on your server.

2. You have a cron job on your server that runs daily, looking for memberships pending expiration. If found, you post the original transaction ID and the last 4 digits to the gateway along with a special variable that tells them to use what's on file.

3. The response is as always, approved/declined/other error, and based on that response the cron job automatically updates their membership or takes other appropriate actions.

This is a completely different approach and I don't find many other providers doing this, it changes everything - I have many customers who can make serious use of this feature.

[Corey Bryant]

These would be done via an electronic payment gateway though, and then the gateway would tell the merchant account to deposit / debit money from the merchant's account.

You can see what the values are of the gateways by going to the gateway's website and reviewing their documents.

-Corey