| Oracle® Retail POS Suite Implementation Guide, Volume 1 – Implementation Solutions Release 14.1 E54475-02 |
|
 Previous |
 Next |
| Oracle® Retail POS Suite Implementation Guide, Volume 1 – Implementation Solutions Release 14.1 E54475-02 |
|
Previous |
Next |
This chapter describes the Authorized Payment Foundation.
The Authorized Payment Foundation (APF) provides a well-defined interface to third-party authorization services and the internal training mode's simulated authorization service by taking advantage of the established Manager/Technician framework and the new Communication Extension (COMMEXT) framework for integrations.
The Point-of-Service client tour sites and aisles populate APF request objects and pass the objects to the PaymentManager. The PaymentManager sends the request to the appropriate connectors and formatters using calls to the Communication Extension (COMMEXT) framework.
The base implementation of APF includes COMMEXT configurations for ACI PinComm and PXP Solutions ANYpay POS authorization services. Base implementation also includes a simulated authorization service for training mode.
The APF removes the handling of sensitive card account numbers from Point-of-Service, removes the direct integration between Point-of-Service and the CPOI device, and improves and isolates the interface between Point-of-Service and the authorization service.
Sensitive credit and debit card account numbers are not handled or persisted by Point-of-Service. The authorization service provides an account number token which is persisted and used in a variety of situations. The masked card number continues to be persisted and is also used.
Each tender is authorized as it is tendered. When a transaction is canceled, or when the tender option screen is left before the tendering is complete, all authorized tenders are reversed.
All CPOI interaction is performed using the authorization service. The granularity of CPOI control is defined by the third-party authorization service.
If the new authorization service requires or returns information different from the information defined in the base APF request or response classes, changes might be required for:
The APF request/response classes
Intermediate Point-of-Service client authorization classses
Database tables
Data persistence classes/SQL
If the new authorization service supports additional features, then Point-of-Service client tours can be extended or modified. For more information, see the Oracle Retail POS Suite Implementation Guide – Volume 2, Extension Solutions.
If the base APF request/response classes are adequate, then you might need to implement new COMMEXT connectors and formatters and modify the COMMEXT configuration only.
The APF classes are described in detail in APF Request Types. These classes might need to be modified to accommodate the new authorization service.
The authorizable tender tables might require modification if information different from the authorization service response must be persisted.
Values returned from PinComm for credit or debit authorizations are stored in the TR_LTM_CRDB_CRD_TN table. Additional information for ANYpay POS is stored in the TR_LTM_CRD_ICC table.
If the new authorization service does not require additional information collection during the Point-of-Service client tour, then tour modifications might not be required.
The authorization service can support different features or require different information. If so, Point-of-Service client tours must be modified to collect the additional information and set the values in the APF request objects. For more information, see the Oracle Retail POS Suite Implementation Guide – Volume 2, Extension Solutions.
Many features in the base product are supported by PinComm but not supported by ANYpay POS (such as House Accounts, Signature Capture, Gift Cards, Scrolling Receipts and Swipe-Ahead). These features are controlled by properties such as SignatureCaptureEnabled, ReturnByAccountNumberToken and POSGFCardTenderEntryRequired located in <source_directory>\applications\pos\deploy\shared\config\application.properties, and parameters such as GiftCardsAccepted and HouseAccountPayment located in <source_directory>\applications\pos\deploy\shared\config\parameter\application\application.xml. Some features, such as Scrolling Receipts, are enabled or disabled using COMMEXT filters. In many cases, tour modification can be avoided by changing these configurations.
New COMMEXT connectors and formatters must be implemented to enable the APF requests and responses to communicate with the requests and responses used by the new authorization service, and to send requests to the new service.
Connectors can also be used to handle more than just sending requests to the auth service. See PinComm Connectors for more information.
The PinComm connector calls an API to send requests to the authorization service. The PinComm implementation has unique formatters for each type of request that is sent to PinComm. The PinComm implementation also uses several connectors to handle special cases.
The ANYpay POS connector opens a socket, through which the connector sends its request. The ANYpay POS implementation uses a single formatter to format all types of requests sent to its authorization service.
|
Note: The implementer must determine which design to use for the new authorization service. |
The COMMEXT configuration file must be modified to use the new connectors and formatters.
The implementer must be familiar with COMMEXT configuration. For more information, see the Oracle Retail POS Suite Implementation Guide – Volume 2, Extension Solutions.
The following files contain the PinComm and ANYpay POS configurations:
PaymentManager.xml
PaymentTechnician.xml
APF request classes are object oriented and are organized to accommodate the different information required for the variety of requests and responses. Note that not all types are supported by the ANYpay POS authorization service.
ReversalRequest inherits from some of the classes used by the authorize payment request. Those classes are excluded here to simplify the diagram. See Figure 10-1, "AuthorizeTransferRequest Class" for more detail. This request reverses previous authorizations. Reversals occur when a sale is canceled before the tendering is completed, and when the operator leaves the tendering screen before tendering is complete.
AuthorizeInstantCreditRequest inherits from some of the classes used by the authorize sale request. Those classes are excluded here to simplify the diagram. See Figure 10-1, "AuthorizeTransferRequest Class" for more detail. This request is used to apply for instant credit (house account) approval.
CallRefferalRequest inherits from some of the classes used by the authorize sale request. Those classes are excluded here to simplify the diagram. See Figure 10-1, "AuthorizeTransferRequest Class" for more detail. This request is used when a call referral is required for authorization.
This request is used to display information such as purchased items and tenders on the CPOI device. This request also controls activation and detection of swipe-ahead capability.
The APF response types follow a parallel hierarchy with their request counterparts.
PaymentManagerIfc is the API used to send all requests to the authorization service (PinComm, ANYpay POS, or training mode auth simulator).
PaymentManger uses COMMEXT to route requests to the appropriate technician.
PaymentManager accepts the request objects defined earlier.
The following tours (services) call PaymentManager:
instantcredit – paymentMgr.authorize(AuthorizeInstantCreditRequestIfc)
main – paymentManager.clearSwipeAheadData()
manager – paymentManager.getStatus()
returns.returnoptions – paymentManager.getCardToken(CardTokenRequestIfc)
sale – paymentManager.clearSwipeAheadData()
signaturecapture – paymentManager.getSignature(SignatureCaptureRequestIfc)
tender – paymentManager.isSwipeAhead()
tender.activation – paymentManager.authorize(AuthorizeTransferRequestIfc)
tender.authorization
paymentManager.authorize(AuthorizeTransferRequestIfc)
paymentManager.authorize(AuthorizeCallReferralRequestIfc)
tender.reversal - paymentManager.reversal(ReversalRequestIfc)
The CPOIPaymentUtility is a wrapper used primarily to send scrolling receipt requests to the PaymentManager. This utility translates information from Point-of-Service objects into CustomerInteractionRequestIfc objects that are passed to paymentManager.show(). The CPOIPaymentUtility is called from any tour (service) that clears, adds or updates line item or tender information on the CPOI device.
If the new authorization service does not support scrolling receipts, the COMMEXT configuration can be modified to filter these types of requests.
This section describes the APF implementation for the PinComm authorization service.
As required by the APF, the PinComm technician uses COMMEXT to route messages to a variety of connectors and formatters which send requests to and receive requests from PinComm.
This configuration is an example of an authorization service that has a single central service for a store.
The base COMMEXT configuration for PinComm routes requests from the Point-of-Service client to the Point-of-Service server, which then sends requests to a PinComm server.
|
Note: Check with your authorization service vendor for the recommended topology. You might want to configure APF so that requests are not sent to the Point-of-Service server. By decoupling the authorization function from the Point-of-Service server, transaction authorizations can continue if the Point-of-Service server is not available to the client. |
The PinComm implementation has several formatters that perform the operations required by the various types of requests.
This connector formats, sends and translates. This is the simplest connector and is used when no special processing or routing is required by a request.
This connector is used primarily for credit, debit and gift card authorizations. A special connector is required because this request is performed in two stages. Stage 1 prompts the customer for the card type, cash back amount (when appropriate), and the amount approval. Stage 2 performs the authorization request. This connector also performs extra processing for the swipe-ahead feature.
The following sequence diagram describes the flow for the CardAuth request. This is the most complex request sequence.
This diagram illustrates the following:
The ability to dispatch COMMEXT messages from within a connector.
The ability to extend COMMEXT with a custom connector to handle flows that the COMMEXT configuration settings cannot handle.
This connector performs the format, send and translate operations for the OnePassCardAuth request . This connector also performs extra processing for the swipe-ahead feature. This connector is used when an authorization is performed without the need to prompt the customer for additional information.
This connector performs the format, send and translate operations for the AuthorizeCallReferralWithoutToken request. It also performs extra processing for the swipe-ahead feature.
This connector does not communicate with the PinComm server. It checks the internal online and offline flags and returns the appropriate response.
This connector includes extra processing required for scrolling receipts.
PinComm has several formatters that perform the operations required by the various types of requests. These formatters translate the APF request objects into a format used by PinComm and translates the PinComm responses into the APF response objects.
Each type of request has its own formatter.
All formatters inherit from the AbstractPinCommFormatter class. The following formatters have more than one level of inheritence.
Many values are configurable in both the APF PinComm technician and the ACI PinComm software. Configurable values for the APF PinComm technician are defined in <source_directory>/applications/pos/deploy/shared/config/PinCommCodes.properties. Many of the values in PinCommCodes.properties must match with values configured in the ACI PinComm installation. The ACI PinComm vendor documentation for configuration details.
The integration between Point-of-Service and PXP Solutions ANYpay POS is accomplished using the Communication Extension (COMMEXT) framework. For PXP Solutions integration, there is only a Manager, with no Technician. The Manager is a COMMEXT variety that knows how to route messages to the PXP Solutions formatter/connector pair. The formatters and connectors split the responsibilities for formatting messages to external systems. The formatters and connectors also split the responsibilities for connecting to those systems.
Abstract base class that is used for formatters that generate and parse XML using JAXB. The class caches JAXB contexts for subsequent use.
Extends the JAXBFormatter class and is responsible for converting to or from PXP Solutions XML. Superclass routines are used to convert the XML into Java objects generated from JAXB. This is the most likely class to extend to provide custom behavior. The methods formatConnectorMessage(MessageIfc) and translateConnectorResponse(Serializable) are the two points of interaction with an instance of this class and the dispatcher.
Abstract connector class that performs some bit of logic, then delegates its message to another connector. In this integration, the chained-to connector is a SocketConnector.
Extends the abstract ChainedConnector and delegates its message to the SocketConnector. ServebaseConnector provides some simple logic to ignore requests from Point-of-Service for device status updates and signature captures, neither of which is supported by PXP Solutions ANYpay POS. Extending this class was not intended.
Given a host name and port number, this connector does the leg work of opening a socket and reading and writing strings to and from ANYpay POS. Default configuration for this connector is to connect to a localhost at port 5000. Extending this class should not be required.
Inner class of SocketConnector that monitors the socket connection for a response.
Figure 10-14 shows how tour sites and aisles of the Point-of-Service application communicates to ANYpay POS. The tour code communicates through a Manager interface as normal. That Manager uses a COMMEXT Dispatcher to route the messages through routes configured for it. The routes are defined for the actions that the tour is trying to perform, for example, authorize an amount for tender or show some information about the sale on the CPOI. The COMMEXT routing also uses filters in this case to redirect these messages while in training mode to separate connectors along the same route.
The COMMEXT framework is used to provide a pluggable and fully configurable integration between Point-of-Service and PXP Solutions ANYpay POS. Only the Point-of-Service client integrates with ANYpay POS. The PaymentManager is defined in the <source_directory>/applications/pos/deploy/client/config/conduit file:
Example 10-1 PaymentManager in pos/config/conduit/ClientConduit.xml
<MANAGER name="PaymentManager"
class="PaymentManager"
package="oracle.retail.stores.domain.manager.payment"
export="N" saveValets="N" singleton="N">
<PROPERTY propname="configScript"
propvalue="classpath://config/manager/PaymentManager.xml"/>
</MANAGER>
The PaymentManager is a COMMEXT BaseManager with its own configuration file, PaymentManager.xml, found in the <source_directory>/applications/pos/deploy/client/config/manager directory. In the PaymentManager.xml file, the message routing components are defined and configured to communicate to ANYpay POS. To generate a custom behavior, extend the ServebaseFormatter and replace it in this configuration.
FILTERS – In the group of filters, there are special filters for handling messages differently in training mode and re-entry mode, and filters for handling gift card requests.
FORMATTERS
PassThruFormatter – The most common formatter, PassThruFormatter is defined and used for training mode. PassThruFormatter does not change the contents of the message before it arrives at a Connector.
ConnectorValetFormatter – This formatter is not used for PXP Solutions integration.
ServebaseFormatter – This is a subclass of a JAXBFormatter. ServebaseFormatter performs the primary work of converting ANYpay POS XML messages into response objects and vice versa. ServebaseFormatter must also be configured with the correct merchantId, customerCode, site, username and password to communicate with ANYpay POS correctly.
RULES
RetryRule – The number of retries can be configured.
StopOnErrorRule – Stops sending the message to connectors upon an error.
DefaultActionRule – The routing rule with a default action (Continue) that occurs upon error.
CONNECTORS
SimulatedAuthConnector and the other simulated connectors are used to generated responses while in training mode.
ServebaseSocketConnector – This connector does the actual work of opening a socket to ANYpay POS and sending or receiving the XML strings. ServebaseSocketConnector should have the hostName and port configuration set to point to where PXP Solutions ANYpay POS is installed. The base product expects ANYpay POS to be in the localhost. The connector should be configured to expect a response from ANYpay POS:
expectResponse = true
ServebaseConnector – This connector is where most messages are routed. ServebaseConnector provides some logic for ignoring some device status requests and rejecting unsupported requests, such as GiftCard and HouseAccount. This connector forwards valid requests to the ServebaseSocketConnector.
ReversalConnector – A file-based queue connector for forwarding the reversal requests to ANYpay POS in a non-synchronous fashion. The interval configurations are in milliseconds.
MSGROUTERS
DEFAULTROUTER – This is the default route that all messages sent from Point-of-Service flow through when a match MSGROUTER type is not found for the message being dispatched. Requests made in training mode are filtered off and handled by the simulated connectors.
Reversals are ignored in training mode and go to the store-and-forward connector, ReversalConnector, in normal mode.
ANYpay POS expects communication in XML format. Refer to the PXP Solutions ANYpay POS (FIXED PED) XML Integration Guide for details about the format of the communication between Point-of-Service and ANYpay POS.
Example 10-2 Request Format
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<IccTransactionRequest xmlns="http://servebase.com/2009/06/pedframework">
<TransactionConfig>
<CustomerCode>ORA</CustomerCode>
<Site>ORA000000001</Site>
<Culture>en</Culture>
<Workstation>001</Workstation>
<MerchantId>21249872</MerchantId>
<Username>ORA-001</Username>
<Password>_F4Rvcf-G</Password>
<IpAddress>127.0.0.1</IpAddress>
</TransactionConfig>
<AuthorizationConnectionType>OnlineAuthorization</AuthorizationConnectionType>
<TransactionAmount currency="GBP">10.00</TransactionAmount>
<TransactionReference>042411290016</TransactionReference>
<TransactionDateTime>2010-11-10T10:10:10.000-06:00</TransactionDateTime>
<TransactionType>Sale</TransactionType>
</IccTransactionRequest>
Although the above example is formatted for readability, the actual XML produced is not formatted.
Example 10-3 Response Format
<?xml version="1.0" encoding="utf-16"?>
<IccTransactionResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://servebase.com/2009/06/pedframework">
<ResponseCode>Approved</ResponseCode>
<ResponseMessage>Transaction Approved</ResponseMessage>
<ReceiptInfo xsi:type="IccReceiptInfo">
<CardNumber>541333******0020</CardNumber>
<ExpiryDate year="14" month="12" />
<StartDate year="4" month="1" />
<TransactionAmount currency="GBP">20.00</TransactionAmount>
<TransactionReference>042411290016</TransactionReference>
<MerchantId>21249872</MerchantId>
<TerminalId>27519414</TerminalId>
<CardScheme code="MSC" creditDebitIndicator="CreditCard">Mastercard</CardScheme>
<CaptureMethod>Icc</CaptureMethod>
<Dcc xsi:nil="true" />
<ApplicationId>A0000000041010</ApplicationId>
<ApplicationLabel>MasterCard</ApplicationLabel>
<PreferredName>MasterCard</PreferredName>
<PanSequenceNumber>00</PanSequenceNumber>
<CvmResults>410302</CvmResults>
<TransactionType>Sale</TransactionType>
<IccAccreditationInfo>
<AuthorisationRequestCryptogram>CB4732891FAF9FEF</AuthorisationRequestCryptogram>
<ApplicationInterchangeProfile>5800</ApplicationInterchangeProfile>
<ApplicationTransactionCounter>0008</ApplicationTransactionCounter>
<UnpredictableNumber>7220921C</UnpredictableNumber>
<TerminalVerificationResult>0000008000</TerminalVerificationResult>
<CryptogramTransactionType>00</CryptogramTransactionType>
<CryptogramInformationData>40</CryptogramInformationData>
<ApplicationResponseCryptogram>DC7AF2C53204A954</ApplicationResponseCryptogram>
<POSEntryMode1>3</POSEntryMode1>
<POSEntryMode2>2</POSEntryMode2>
<ApplicationUsageControl>FF00</ApplicationUsageControl>
<ApplicationVersionNumber>0002</ApplicationVersionNumber>
<TerminalApplicationVersionNumber>0002</TerminalApplicationVersionNumber>
<TransactionStatusInformation>E800</TransactionStatusInformation>
<TerminalType>22</TerminalType>
<TerminalCapabilities>E0B8C8</TerminalCapabilities>
<IssuerActionCodesOnline>F870A49800</IssuerActionCodesOnline>
<IssuerActionCodesDenial>0000000000</IssuerActionCodesDenial>
<IssuerActionCodesDefault>FC50A00000</IssuerActionCodesDefault>
<IssuerApplicationData>021265100F040000DAC000000000000000FF</IssuerApplicationData>
<AuthorisationResponseCode>00</AuthorisationResponseCode>
<TerminalCountryCode>0826</TerminalCountryCode>
<TerminalCurrencyNumber>826</TerminalCurrencyNumber>
</IccAccreditationInfo>
</ReceiptInfo>
<Token>7a0351bf-277f-4340-a811-0ab026e886b8</Token>
<AuthorityCode>006375</AuthorityCode>
<IssuerAuthenticationData>DC7AF2C53204A9540012</IssuerAuthenticationData>
</IccTransactionResponse>
The following are some notes about the translation of response code for PXP Solutions:
If ANYpay POS responds with an ERROR or DECLINED response code, and the message Failed to communicate, then Point-of-Service treats that as a Referral response and follows the appropriate flow.
If ANYpay POS responds with a CANCELLED response code, and the message did not response in the configured time span, then Point-of-Service treats that as a Timeout and follows the appropriate flow.
The ANYpay POS CaptureMethod KEYED is translated as the Point-of-Service EntryMethod Swiped.
This section describes the APF implementation for the AJB authorization service.
As required by the APF, the AJB technician uses COMMEXT to route messages to a variety of connectors and formatters which send requests to and receive responses from AJB.
An AJB server (FIPAYEPS) can service a single register (associated with the Point-of-Service client) or multiple registers (associated with the Point-of-Service store server).
FIPAYEPS does not need to be installed on the register or the store server. Point-of-Service and FIPAYEPS communicate using TCP/IP. Therefore, FIPAYEPS only needs to be accessible somewhere on the network.
For Mobile Point-of-Service, an AJB server can be associated with all Mobile Point-of-Service registers (serviced by the Mobile Point-of-Service server) or the Mobile Point-of-Service server can be configured to use an AJB server associated with the Point-of-Service store server.
For the recommended topology for a specific retailer's needs, consult with AJB.
The following AJB connectors send and receive messages to and from FIPAYEPS:
AJBCardAuthCallReferralConnector
AJBCardAuthConnector
AJBCardAuthRefundReentryConnector
AJBCardRefundConnector
AJBCardReversalConnector
AJBCheckCallReferralConnector
AJBCheckConnector
AJBConnector
AJBCPOIConnector
AJBReentryAuthConnector
AJBConnector is the simple case where a message is sent and the response is returned.
All other connectors examine the response's values to determine if more actions are required. For example, AJBCardAuthConnector checks the authorization response for a bank down condition. If the bank is down and the authorization amount is lower than the floor limit defined for Point-of-Service, a forced-auth store-and-forward request is sent to the AJB server for later transmission to the bank.
The following formatters translate the various Point-of-Service requests (AuthorizeTransferRequestIfc) into AJB-specific request messages. Formatters also translate AJB-specific response messages into the various Point-of-Service responses (AuthorizeTransferResponseIfc):
AJBAcceptECheckFormatter
AJBCardAuthCallReferralFormatter
AJBCardAuthFormatter
AJBCardAuthFormatterManualEntry
AJBCardAuthFormatterSAF
AJBCardAuthFormatterUS
AJBCardAuthReentryFormatter
AJBCardAuthRefundReentryFormatter
AJBCardRefundFormatter
AJBCardRefundFormatterSAF
AJBCardReversalFormatter
AJBCheckFormatter
AJBGiftCardFormatter
AJBHouseAccountAuthFormatter
AJBHouseAccountAuthRefundFormatter
AJBHouseAccountPaymentFormatter
AJBInstantCreditFormatter
AJBScrollingReceiptFormatter
AJBSignatureCaptureFormatter
AJB uses many internal code values that are used by the AJB Technician. These codes are defined as a Java enum type in the AJBCodes class. The values associated with each enum value are defined in AJBCodes.properties. In some cases, the behavior of the AJB Technician can be customized by modifying the code values in AJBCodes.properties.
The following classes contain helper utility functions that support the connectors and formatters:
AJBFormatUtilsIfc
AJBFormatUtils
This section provides a reference on how action codes are mapped to Point-of-Service authorization responses.
The following tables define the AJB action codes and SPDH codes.
Table 10-1 AJB Action Codes
| Action Code | Definition |
|---|---|
|
0 |
Authorized/Approved/Successful |
|
1 |
Declined |
|
2 |
Call Referral |
|
3 |
Bank Down |
|
5 |
Comm Issue |
|
6 |
Report Error (Formatting problem; treat like a hard decline) |
|
8 |
Try later |
|
10 |
Timed Out |
|
12 |
Approved Administration |
|
14 |
MAC Failure |
The following tables summarize how Point-of-Service determines the response codes, gift card status codes, and financial network status codes based on the AJB action codes and AJB SPDH codes:
The tables contain evaluation rules which are evaluated from top to bottom.
An asterisk (*) indicates a wildcard where any value is considered a match. For example, with Credit/Debit, the AJB action code is not considered when evaluating device timeouts and cancellations by the customer.
When no matches occur, the last rule in the table is used. The last rule has wildcards for both the AJB action code and AJB SPDH code.
Table 10-4 Credit/Debit Including Gift Card Tender Swiped at the PinPad
| AJB Action Code | AJB SPDH Code | ORPOS Response Code | ORPOS Gift Card Status | ORPOS Financial Network Status |
|---|---|---|---|---|
|
* |
|
DeviceTimeout |
Unknown |
ONLINE |
|
* |
TRANSACTION_CANCELLED_BY_PIN_DEVICE |
InquiryForTenderCanceledByCustomer |
Unknown |
ONLINE |
|
AUTHORIZED |
* |
|
Active |
ONLINE |
|
DECLINED |
* |
Declined |
Inactive |
ONLINE |
|
CALL_REFERRAL |
* |
Referral |
Timeout |
ONLINE |
|
BANK_DOWN |
* |
Offline |
Timeout |
BANK_OFFLINE |
|
* |
Offline |
Timeout |
ONLINE |
|
* |
* |
Declined |
Inactive |
PAYMENT_APPLICATION_OFFLINE |
Table 10-5 Check/E-Check
| AJB Action Code | ORPOS Response Code | ORPOS Financial Network Status |
|---|---|---|
|
AUTHORIZED |
Approved |
ONLINE |
|
DECLINED |
Declined |
ONLINE |
|
CALL_REFERRAL |
Referral |
ONLINE |
|
BANK_DOWN |
Offline |
BANK_OFFLINE |
|
Offline |
ONLINE |
|
* |
Declined |
PAYMENT_APPLICATION_OFFLINE |
Table 10-6 Gift Card
| AJB Action Code | ORPOS Response Code | ORPOS Gift Card Status | ORPOS Financial Network Status |
|---|---|---|---|
|
AUTHORIZED |
|
Active |
ONLINE |
|
DECLINED |
Declined |
Inactive |
ONLINE |
|
CALL_REFERRAL |
Referral |
Timeout |
ONLINE |
|
BANK_DOWN |
Offline |
Timeout |
BANK_OFFLINE |
|
Offline |
Timeout |
ONLINE |
|
* |
Declined |
Inactive |
PAYMENT_APPLICATION_OFFLINE |
Table 10-7 House Account Payment
| AJB Action Code | ORPOS Response Code | ORPOS Financial Network Status |
|---|---|---|
|
AUTHORIZED |
Approved |
ONLINE |
|
DECLINED |
Declined |
ONLINE |
|
CALL_REFERRAL |
Referral |
ONLINE |
|
BANK_DOWN |
Offline |
BANK_OFFLINE |
|
Offline |
ONLINE |
|
* |
Declined |
PAYMENT_APPLICATION_OFFLINE |
Table 10-8 Instant Credit
| AJB Action Code | ORPOS Response Code | ORPOS Financial Network Status |
|---|---|---|
|
AUTHORIZED |
Approved |
ONLINE |
|
DECLINED |
Declined |
ONLINE |
|
CALL_REFERRAL |
Referral |
ONLINE |
|
PENDING |
Unknown |
ONLINE |
|
FORMAT_ERROR |
Unknown |
ONLINE |
|
DUPLICATE |
Duplicate |
ONLINE |
|
COMPLETE_OFFER |
Unknown |
ONLINE |
|
* |
Unknown |
PAYMENT_APPLICATION_OFFLINE |
Table 10-9 Credit Re-Entry Mode
| AJB Action Code | AJB SPDH Code | ORPOS Response Code | ORPOS Gift Card Status | ORPOS Financial Network Status |
|---|---|---|---|---|
|
* |
|
DeviceTimeout |
Active |
ONLINE |
|
* |
TRANSACTION_CANCELLED_BY_PIN_DEVICE |
InquiryForTenderCanceledByCustomer |
Active |
ONLINE |
|
BANK_DOWN |
* |
Offline |
Timeout |
BANK_OFFLINE |
|
* |
Offline |
Timeout |
ONLINE |
|
* |
* |
Approved |
Active |
PAYMENT_APPLICATION_OFFLINE |
In training mode, authorization request messages from Point-of-Service are intercepted by filters in the COMMEXT configuration. The requests are redirected to code that provides simulated responses. Depending on the digit in the ones column authorization amount request, the system provides a different response (for reference, $12.34 has a 2 in the ones column).
