Several years ago, the credit card processing companies implemented a new anti-fraud scheme to make using stored credit card information safer when this information was used in an automatic recurring payments scenario. Basically, the processor will issue a special identifier string in response to the first transaction in the chain of recurring transactions using a stored credit card. For every subsequent scheduled recurring charge in the chain, this identifier must be sent in to the processor. Each processor response will also contain a new identifier. When issuing a sale (past the first one) that is part of a recurring chain of sales using a stored credit card, you have to either provide the first or latest identifier. Each scheduled chain of recurring payments using a stored card must keep track of its own identifier even if two schedules use the same credit card; the identifier is for the scheduled chain not for the credit card used.
In general, what processors consider to be a “recurring” payment is a transaction for the same amount on the same day of a single time cycle. For example, $50 on the 15th of every month or $10.50 every two weeks over a large period of time. Monthly billing where a month’s worth of charges is added up (even if they sometimes add up to the same amount) is not considered recurring because the amount is determined each time period and is not a set amount to be charged. For something like a scheduled payment of $35 to be billed at the end of each month for 15 months or for an unlimited time period IS considered to be a recurring payment. One other thing that requires you to use this functionality is if you have the card holder’s billing information stored and the transaction is created with no involvement of that card holder.
We understand that this is a confusing subject. Please contact Constellation Payments to have a conversation about your specific situation and determine your requirements for using the API.
To enable users to handle this requirement, the sale request (this functionality not available with Authorize) contains an element called “recurring”. There are 4 possible values for this element:
| None | The transaction is not part of a recurring schedule track |
| NoTrack | The transaction is recurring but the account type does not require recurring schedule tracking. At this time, AMEX and ACH (checking/savings) accounts do not require this scheme. |
| First | The transaction is the first one in the recurring schedule track. Remember to query the recurring session identifier from the response to this first transaction. |
| InTrack | This transaction is part of a stored credential recurring schedule track after the first transaction. Remember that you will need to provide, for this transaction, the session ID you obtained from the first response. |
The response to the first sale transaction of a schedule track will include an element called “recurringScheduleTransId” that will contain the identifier that was created by the processor. For all subsequent sales for that schedule transaction chain, you will designate that this is a recurring sale by setting the “recurring” element to “InTrack” and you will supply the processor’s identifier.
This functionality is not available when you are using the Authorize/Capture APIs.