External Payment Service

External payment service is a RESTful web service that provides an interface from Order Administration for sending stored value card transactions and receiving responses. Using this service, you can build a custom payment processor that maps to your payment provider.

This payment service needs to be configured to use the integration layer component of Order Administration, as this component controls payment service processing.

The workflow for External Payment Services

Supported stored value card transactions:

activation request
authorization request
balance inquiry
deposit request
generation request
recharge request
return request
reversal request

For more information: For background on stored value card authorization, see:

Defining Authorization Services (WASV)

In this topic:

For sample messages see the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).

External Payment Service Setup

The required setup for the External Payment Service is described below, and includes:

Additional security requirements: For additional security-related setup requirements, including implementation of OAuth, see the External Payment Service Technical Reference Paper on My Oracle Support (2149144.1).

Secured Feature

The External Authorization Service Access (B25) secured feature controls access to the Work with External Authorization Service Screen, where you can work with required settings for the External Payment Service. These settings are described briefly below under External Service Settings

Authentication

Use OAuth to authenticate the External Payment Service. See the Oracle Retail Omnichannel Web Service Authentication Guide on My Oracle Support (2728265.1) for more information.

Authorization Service Settings

Use Defining Authorization Services (WASV) to create a service bureau for the External Payment Service.

Settings for External Payment Service: The following table lists some of the required settings, in addition to the basic settings required for all service bureaus and any optional settings, to support the External Payment Service.

Fields at the first Create/Change/Display Authorization Services screen include:	Description
Service Code	Typically set to EXT or EXC, but can be set to anything.
Application	Select Auth/Deposit.
Void auth at deposit	Select this field to void any unused portion of a credit card or stored value card authorization at deposit time. Note: The Retain Unused Stored Value Card Authorization After Deposit (J21) system control value does not control stored value card deposit updates for the External Payment Layer.
Send reversal	Select this field to perform a credit card authorization reversal when you process a cancellation associated with a credit card payment or deactivate a credit card payment.
Fields at the second Create/Change/Display Authorization Services screen:
Media type	Select Communication.
Batch/Online	Select Online or Batch.
Immediate response	Must be selected.
Primary authorization service	Should be blank
Communication type	Payment Link must be selected, to indicate messages sent the external payment layer are processed directly.
Response check frequency	Indicates the multiple to apply to the Response time to determine how long to wait for a response after a connection when you are using the External Payment Service. For example, if the Response check frequency is 6 and the Response time is 10,000, the system waits 60,000 milliseconds (60 seconds or 1 minute) for a response after connection. Note: If the total response interval is exceeded for an authorization record, the record goes into *RCVD status with a response type of SU, and is then removed from the Credit Card Authorization Transaction table (CCAT00).
Response time	Indicates the number of milliseconds to wait for a connection to the service bureau when you are using the External Payment Service. For example, set this field to 10,000 milliseconds to wait 10 seconds for a connection. Note: Order Management System does not wait the entire response time if it is not necessary. To avoid potential timeout issues, Oracle recommends that you set the Response Time high enough for the authorization service to prevent issues that could potentially occur if the authorization process times out while processing multiple authorizations for an order.
Country codes	If needed, define a cross reference between your country code and the country code used by the service bureau. Note: This option also indicates whether a service bureau performs address verification processing for the country. See Defining Authorization Service Countries.
Currency codes	If needed, define a cross reference between your currency code and the currency code used by the service bureau; see Defining Authorization Service Currencies.
Merchant ID Override	If needed, define a merchant ID override for the different entities in your company; see Defining Merchant ID Overrides.
Paytype codes	If needed, define a cross reference between your pay type code and the pay type code used by the service bureau; see Defining Vendor Paytype Codes.
Response codes	Define the reasons that the service bureau approves (authorizes) or declines a transaction. The codes are assigned to each transaction by the service bureau when approving or declining the request; see Defining Vendor Response Codes. A response code of SU, indicating service unavailable, must be created. When there is a REJECT or ERROR response, the order goes on AT hold and the authorization is updated as declined when: The reason code passed is not defined as an authorization response code, or The reason code passed is defined as an authorization response code but also has a hold code defined, or No reason code is passed. If no reason code is passed, a response code of SU is applied.

External Service Settings

The additional External Service Settings at the Work with External Authorization Service Screen are accessible only to users with External Authorization Service Access (B25) authority.

All fields on the screen are required, with the exception of the External Service flag.

Tracking changes to external service settings: Changes that users make to external service settings are tracked in the User Audit table, and listed on the User Authority Change report. See Tracking User, Authority, and Password Updates for more information.

For more information: See the External Payment Layer RESTful Service technical reference on My Oracle Support for more information on updating these settings.

Setting	Notes
External Service	Select this field to have request messages generated for the External Payment Service.
External URL Prefix	The prefix that forms the beginning of the URL where messages are sent. Must begin with https. The message type defines the endpoint suffix that is appended to the prefix, creating the entire URL. For example, for a credit card authorization request, the entire URL might be https://remote.auth.com:1234/authorization, where remote.auth.com is the remote server, 1234 is the port, and authorization identifies an authorization request. The following endpoints are supported: balanceInquiry authorization reversal getToken generateGift activateGift rechargeGift deposit return
Message Version	Indicates which message version is supported with version 3.0 being the default version when creating a new authorization service. Previous versions have been removed. Version 3.0 no longer includes tags that pass the credit card number for an order and instead includes tags that pass the card token. It also allows an external merchant application to call for both Credit Cards and Stored Value Cards supported through the External Payment Service and EFTConnect.
Authentication User	The user ID for authentication of the messages to the external service.
Authentication Password	The password for authentication of the messages to the external service. Must be at least 6 positions long, include both numbers and letters, include a special character, and cannot end with a number.

Work with Pay Types (WPAY)

Use Working with Pay Types (WPAY) to assign the authorization and deposit service to each credit card or stored value card pay type that uses the External Payment Service.

Work with Order Types (WOTY)

In order to perform online authorization on web orders, the Online Authorization setting for the order type on the web order must be set to Without Window. See Establishing Order Types (WOTY) for more information on setting up an order type.

Stored Value Card Reversal Function

You can use a periodic function, described below, to submit stored value card reversal requests for closed or canceled orders.

REVXAHP (Program name = PFREVXAHP): Reverse Partial Auth for External Payment Service: Generates SVC reversal request messages for the External Payment Service within the specified company, provided that:

A company is specified.
The parameter specified for the function is a valid stored value card pay type code for the company.
The pay type is assigned to an authorization service configured as the External Payment Service.
The pay type does not match the Default Auth Code for CC Netting (M25) system control value.

For more information: See Stored Value Card Authorization Reversal for an overview of the authorization reversal process.

Subsequent Authorization Requests through the External Payment Service

About subsequent authorizations: Order Management System sends information through the External Payment Service indicating whether a transaction was initiated by the merchant, or by the customer. For example, when the customer initially places the order, this is a transaction initiated by the customer; an example of a merchant-initiated transaction is a subsequent authorization that is acquired by Order Administration when the initial authorization is expired.

Message version: Additional tags are available to support passing information identifying a subsequent authorization that was not initiated by the customer. You need to have a version 3.0 selected for the External Payment Service to use the new tags. See External Service Settings for more information.

Term definitions:

Merchant-Initiated Transactions (MIT): An authorization that the system initiates without the customer’s active participation.
Cardholder-Initiated Transactions (CIT): An authorization that uses payment information provided by the customer.
Credentials on File (COF): The cardholder payment information that is stored by the system.

Types of subsequent authorizations: Brief descriptions of subsequent authorization types for credit cards include:

Resubmission of a failed deposit: When the Supports Auth Resubmission flag is selected for the authorization service in Defining Authorization Services (WASV) and a previous deposit request for the credit card failed. A subsequent authorization and deposit request is generated, with the subsequentAuth tag set to Y and the subsequentAuthReason set to RESUBMIT. However, if the Supports Auth Resubmission flag is not selected, the subsequentAuthReason is set to REAUTH.
Split shipment: When the order is not fulfilled in a single shipment. In this case, the request for the subsequent authorization includes a subsequentAuthReason set to REAUTH and passes the existing ci_transaction_id as the subsequentAuthTransactionID.
Deferred or installment billing: When the order uses deferred or installment billing. The pay type’s Notify of installments setting indicates whether to send the subsequentAuthReason set to INSTALLMENT or REAUTH. See Deferred/Installment Billing Overview for background.
Customer membership orders: When you generate orders for a customer membership that has been authorized. Authorization can take place either through the order originating the customer membership, or through a generated membership order. The CIT Transaction ID (customer-initiated transaction ID) and the original authorization amount are stored on the customer membership, although this information is not displayed on any screen. For more information, see Subsequent Authorizations through the External Payment Service for Membership Orders.

Details on the tags in the authorization request message supporting subsequent authorization requests: See the Order Administration Web Services Guide on My Oracle Support (ID 2953017.1).