Processing credit cards is an integral part of receiving revenue. This article will help answer the question- How does Credit Card Processing work? CRM has only two processes that can charge a credit card: “Credit Card Processing process”, and “Add a Payment”. (BBIS is separate, utilizing payment forms for Web Transactions). Here are the detailed steps to process credit cards with an Enhanced Revenue Batch in a Credit Card Process.
In any normal batch, you start off with both good rows and invalid rows in the batch. When you click Validate, the invalid rows get flagged. The good rows are not yet committed, they are just not flagged. Then, when you click Commit, the good rows get committed, and stay in the batch as a Committed Batch in the Committed Batches tab. The problem rows go into an exception batch. But Enhanced Revenue Batches work slightly different.
Please note: The Enhanced Revenue Batch does not charge credit cards by itself. CRM has only two processes that can charge a credit card: “Credit Card Processing process”, and “Add a Payment”. BBIS is separate.
With an Enhanced Revenue batch, you start off with both good and invalid rows in the batch. When you click Validate, the data is checked against constraints, and the problem rows get flagged if the card is not 16 digits, or it’s expired, etc (these are obvious problems with the data- BBPS is not yet involved). The good rows are not flagged, charged, nor committed yet. You have to put the Enhanced Revenue Batch into the Credit Card Processing process in order to send the cards to BBPS and find out if they are authorized/rejected.
When you put the Enhanced Revenue Batch into a Credit Card Processing process, then the process will go through each row and get authorization/rejection codes for each row from BBPS. It won't commit these rows. It'll just put it into a batch with the codes. There are 3 kinds of codes:
1) This row is Authorized, and ready to commit successfully. To indicate this, BBPS puts an authorization code that starts with “Y” in the Authorization code field of the revenue batch.
2) This row is a Provisional rejection. It is possible to retry it successfully. BBPS adds “N” to the front of the authorization code to indicate this.
3) This row is a Permanent rejection which will never successfully go through. BBPS adds “N” to the front of the authorization code to indicate this.
When CRM receives the response, it removes “N” from the authorization code, converts the code to text, and puts the text in the Rejection Code field of the revenue batch. The Credit Card Processing process handles rejections according to the settings in the Rejection Handling tab. You can open the batch with the new authorization codes in each row.
Then, if you click Commit, the good rows get committed, and stay in the batch as a Committed Batch in the Committed Batches tab.
The problem rows with a Provisional rejection go into a Retry batch (if you have that option selected in the Rejection Handling tab of the Credit Card Processing).
The problem rows with a Permanent rejection go into a file via an export definition (if you have that option selected in the Rejection Handling tab of the Credit Card Processing process). The other option is to ignore these rows.