AbleCommerce Shopping Cart Software

One of our clients has received this info. Will Able need any changes?
We’re Changing the Way Transactions are Numbered
Orbital® Payment Gateway – Performance Enhancements
We will be implementing changes to the Orbital Gateway that may affect the way that you monitor your authorizations or submit subsequent transactions. This modification is important if your company utilizes assigned index numbers. For each transaction request in any series of transactions, the assigned index numbers will be incremental but may not be consecutive.

ASSIGNED INDEX NUMBERS
The assigned index number serves as a follow-up number that allows you to identify each transaction related to an order, such as purchases in a split shipment or a full capture after the initial authorization request. Index numbers may also be used in internal processes for monitoring payment status or for reversal requests.

WHAT’S CHANGING?
Currently, the transaction index number for initial authorizations is 0. Subsequent capture requests in a series are assigned as “1, 2, 3 …” With the new implementation, the transaction index number for initial authorizations will continue to be “0”; however, subsequent capture requests may be assigned as “2, 3, 5 …” This means that while the index number will continue to increase, it may no longer be consecutive in sequence.
STEPS TO REMEMBER
• The initial transaction will always have an index number of “0”. Subsequent transaction requests within a series will be incremental, but may not be consecutive.
• Always refer to the response from the Orbital Gateway. Please update internal processes as necessary if your company has implemented an automatic process for monitoring index numbers. Ensure that the correct index number is referenced when submitting adjustment requests.
• This enhancement only affects the index numbers. Transaction Reference Numbers and “split” Transaction Reference Numbers will continue to remain unique for each transaction. If you do not monitor index numbers, or if you process exclusively through the Virtual Terminal, your authorization process will not be impacted by this implementation.

Would be nice if we could do refunds from within AC for orbital gateway as well.

It sounds like it will be OK, but I will have the dev team take a look at what you've posted and confirm one way or the other.

Would be nice if we could do refunds from within AC for orbital gateway as well.

This gateway should support: Authorize, Authorize Capture, Capture, Void, & Refund

Reviewed the Paymentech Orbital code. Our implementation does not make assumptions based on index numbers. We always refer to the response returned by Orbital. I can therefore assume, with reasonable confidence, that our implementation is not affected by the changes discussed above.

Katie wrote:It sounds like it will be OK, but I will have the dev team take a look at what you've posted and confirm one way or the other.

Would be nice if we could do refunds from within AC for orbital gateway as well.

This gateway should support: Authorize, Authorize Capture, Capture, Void, & Refund

Is this only possible if I store credit card numbers? Currently if I click refund it wants to know all the card info. Can it not be setup to use a reference number or something?

Each gateway is different, and yes, they usually require a partial credit card number (e.g. Authorize.net), or the full card info. If you store the credit card number, just be sure to have an encryption key set and the information will only be decrypted when you view the details through the order admin.