Cashiering setup

To create your web form, you will use the Cashiering Setup page in Infor Public Sector.

For more information, see the Cashiering documentation in the Infor Public Sector User and Administration Library on docs.infor.com.

Add a new merchant account and select Web Form in the Payment Server Gateway list. When you select Web Form, two additional tabs are displayed: Client Form and Payments.

The client form is the pay form being rendered and used in the checkout process. The data entered (credit card or other sensitive information) will be posted directly to the payment gateway provider.

Generally speaking, the payment gateway will provide some sort of identification values to identify where the payment goes. The identification must be a one time use token for a particular pay session so public users won't be able to access the merchant account using the same identification. That will also prevent hackers from altering the paying items.

Localization

In the HTML web form you can use localized strings to globalize your pay form. This can be done by using the help with JavaScript. By inserting a script block within the HTML, you can use the Rhythm for Civics i18n.t function to retrieve a localized string value and set it to any control. Example:


<label id="custom" class="input-label" for="card-name">Name on Card </label>
<script type="text/javascript">
 $("#custom").text( i18n.t("CIVICS.CHECKOUT.ACCOUNT_HOLDER") )
</script>

Validation

Required fields will be validated if the form inputs are tagged with the Rhythm for Civics "Required" attribute. If the input control contains the "Required" attribute, Rhythm for Civics will ensure that the control has a value before the form is posted to the payment gateway.

Address verification service (AVS)

The address verification service (AVS) is used to protect against credit card fraud. An AVS mismatch error occurs when the billing address provided during checkout does not match the billing address that you have on record with your credit card company or card-issuing bank.

When a web form payment gateway is used, the billing information is hosted and rendered in Rhythm for Civics. To send the billing information to the payment gateway server for address verification, the corresponding billing hidden inputs must be added to the web form.

Before the pay form is posted, Rhythm for Civics looks at the pay form and tries to locate any input with a class name "avs-address1." If this input field is found, the address line 1 value of the billing information will be copied to this input field. Rhythm for Civics will also try to locate any input with a class name "avs-postal." If this input field is found, the zip code value of the billing information will be copied to this input field.

Payments

During the payment process, different actions are performed at different stages depending on the payment gateway service provider. For a web form payment gateway integration, a client web form is used to post the credit card data directly to the payment gateway server. Authorize and reverse payment are required for the web form payment gateway integration as these are the standard implementation for a standard cashiering payment gateway integration.

Prepare Payment
PreAuthorize Payment
Void Payment
Authorize Payment
Inquire Payment
Reverse Payment
Inquire Reversed Payment

This table shows the detailed behavior of each payment configuration:


Payment configuration	Success	Fail	Triggers
Prepare Payment	Initialized	Declined	When the checkout page is opened
PreAuthorize Payment	Authorized	Declined	When user clicks Continue in the step 1 page going to the review page, it posts the data to the payment gateway based on the form action and invoke PreAuthorize Payment along with the return data from the form post action. This stage will hold the credit of the credit card.
Void Payment	Completed	Failed	When users cancel the payment after the payment is authorized or when errors arise during Authorize Payment.
Authorize Payment	Approved	Declined	When the rhythm user is taken back to the hosted return page
Inquire Payment	Approved	Authorize and capture: Authorized Purchase/none: Initialized	Batch task: Clean up Pending Cashiering Register Transaction
Reverse Payment	Completed	Failed	Batch task: Clean up Pending Cashiering Register Transaction
Inquire Reversed Payment	Completed	Failed	Batch task: Clean up Pending Cashiering Register Transaction

Note: For Reverse Payment and Inquire Reversed Payment, the status is set on the voided payment server transaction.

Template variables

Template variables can be used to represent values from the Infor Public Sector database. When the web profile in each payment tab is executed, or when the redirect URL is constructed, a template utility parses the content into template tokens. Each token is parsed and replaced with the appropriate value. In the hosted page payment gateway integration, the merchant account being used by the portal register, the current drawer transaction, and its corresponding payment server transaction are passed to the template engine.

This table shows some examples of template variables:


Entry	Source	Examples
Redirect URL: Contents	oMerchantAccount oDrawerTransaction oPaymentServerTransaction ServerApplication	{{oDrawerTransaction.RegisterTransaction. RegisterTransactionNumber}} {{oDrawerTransaction.RegisterTransaction. TransactionToken}} {{oMerchantAccount. MerchantAccountCustPropToMerchantAccount. Get("variable1")}}
In all payment configurations: Host Address	oMerchantAccount oDrawerTransaction oPaymentServerTransaction ServerApplication	https://`server`/ services/v1a/shared-services/payments/ transactions/ {{oPaymentServerTransaction.CustomProperties. Get("resultId")}}
In all payment configurations: Contents	oMerchantAccount oDrawerTransaction oPaymentServerTransaction ServerApplication	{{oDrawerTransaction.RegisterTransaction. RegisterTransactionNumber}} {{oDrawerTransaction.RegisterTransaction. TransactionToken}}

Security

When configuring the payment gateway integration in the merchant account setup, you will often include API keys, user names or passwords in the requests. To securely store sensitive data in the database, you can use the merchant account's custom properties on the Account Information tab.

To enable this feature, select the Encrypt Custom Properties check box. Any new entries added to the merchant account's custom properties will be encrypted. To retrieve the data, you can use the template variable and refer to oMerchantAccount.MerchantAccountCustPropToMerchantAccount.Get("***custom prop name****") anywhere in the host address, content or formula.