Buisness-Rules
Accepting Payments in a Retail Environment:
Retail environments traditionally process real-time payments for the purchase of goods and services. A retailer can accept credit cards, debit cards, checks, and gift/loyalty cards. Most transactions can be swiped or keyed, although swiped is usually preferred. Keyed transactions, when allowed, usually result in higher processing fees to the retailer.
Retail transactions:
Retail transactions are usually performed during a single interaction with the processing system, using the SALE transaction type. Transactions processed for certain types of business or commercial credit cards are often accompanied by additional data. When requested by the system, an additional transaction can be performed to UPDATE this information if it was not originally provided as part of the SALE.In certain situations (such as with corporate cards or check images) additional data may need to be sent in a secondary transaction or process.
Swiped vs. Keyed
In the retail environment, transactions are usually processed by swiping the credit card through a magnetic card reader. When a card is swiped only the fields trackdata and the amount needs to be supplied. When a card is manually entered or keyed, additional data may be sent as a fraud reduction tool and to avoid processing penalty fees. This additional data includes items such as the cardholders zip code or the CVV2 value from the back of the card.
Voice Authorizations:
This occurs when a swiped or keyed transaction returns a message to call the processing center. When the retailer calls the center as instructed, they may be given a voice authorization code. This must be processed into the system so the merchant will be paid for the authorization. An OFFLINE transaction is used for this purpose. The OFFLINE transaction functions the same way a SALE transaction does, except the voice authorization authcode is supplied as part of the transaction.
Batching out
The system automatically BATCHs transactions every day. This functionality can be overridden so that only manual Batching occurs. There are also Batch close commands available within the web-based user interface and through the programmers API toolkit.
Any Batch errors that may occur result in a declined Batch close, and a notification will be sent to the administrator of the processing system so the Batch can be successfully closed on the merchants behalf. Once a Batch is closed, certain transactions cannot be performed on items in the Batch. This includes the VOID, UPDATE, and TIPEDIT transactions.
Reports:
Reporting tools are available online from the web-based user interface. The programmers API also includes tools that download the data necessary to produce a variety of reports.
There are specific requirements for each type of payment:
Credit cards are usually the easiest to implement, as they may be swiped or keyed and can be pre-authorized with a tip added later.
Debit transactions need to be accompanied by a PINBLOCK that contains the encrypted pin information from a physical hardware pinpad device. The tip may need to be pre-determined, as a pre-authorised” with tip added later.
Check processing usually requires hardware to read the checks MICR data or to scan the entire check as an image.
o Check verification / guarantee services are done in a single step, often using a MICR reader to acquire the checks bank information.
o Check truncation / conversion services require an image of the check to be uploaded after the transaction is approved.
Gift/Loyalty cards may impose additional receipt requirements and additional balance inquiry functions may need to be supported for the retailer to participate in the gift card programs.