Payments made by subscribers and carriers/dealers are often by credit card. To process the credit card payment and insure that the credit card information is valid, payment authorization is typically done using a third party authorization vendor such as Braintree, Payway Complete or Cybersource. The vendor authenticates the card information with the financial institution issuing the card and, when the payment is accepted, posts the credit card charge or refund. Authorization is usually done in real time so that the user knows immediately whether the payment has been authorized. The text of the authorization messages that display in Customer Service and iServices during this process can be defined in .
To avoid compromising sensitive data, credit card numbers associated with payments are typically not accessible in Circulation. Instead, a token provided by the authorization vendor is displayed, along with the last four digits of the card number. This is known as tokenization. Most tokenized environments also feature off-site credit card storage where the full credit card numbers are not stored in Circulation at all. In environments where credit card numbers are not tokenized and off-site, NAVIGA strongly recommends encrypting the numbers in the database (see in the Setup Manual).
An additional level of security is offered if you use Circulation’s Hosted Order Page (HOP). With a HOP solution, no credit card information is actually entered in Circulation or iServices, even through the user interface. Instead, the HOP is called from the credit card authorization provider’s system and entered in a separate browser window. Using a HOP places Circulation out of scope for compliance with PCI (Payment Card Industry) standards. Circulation supports credit card entry via a HOP for Braintree, Payway Complete, Cybersource and other vendors.
Note:
Real-time credit card authorization and the Hosted Order Page are a licensed, add-on options in Circulation. Contact Newscycle Support for licensing information. In addition, the use of third-party solutions requires a separate contract with the service provider.
Most real time payment authorization solutions use Circulation’s Payment Authorization Service (PAS), a web service that communicates between Circulation and the authorization vendor. (The exception is viaWarp.) To use the PAS, the Business Rule— Which product integration is used for real-time payment authorization? (Payment Auth - Account and Payment Auth - Subscrib sections) should be set to “DTI”.
Business Rules in the Payment Auth - Account and Payment Auth - Subscrib sections determine the host name, URL, payment authorization vendor and other parameters for the Payment Authorization Service. See Tech FAQ #13 for information in installing the Payment Authorization Service.
In a tokenized environment, full credit card numbers are typically not stored in the Circulation database, even in encrypted form. Instead the PAS sends back a token, also known as a vault ID, which is the ID of the record where the number is stored in the vendor’s credit card vault. In this environment a masked credit card number is stored in Circulation for display purposes. A masked credit card number will typically be displayed as ************0123, with only the last four digits visible to the user. See in the Setup Manual for more information.
Note:
In some cases, such as conversion or Lockbox Processing, not even a masked credit card number may be provided with the vault ID. In these cases “VAULTED VALUE” is stored as the credit card number.
The diagram below illustrates how credit card numbers are tokenized by the credit card vendor, and a token returned via the PAS.
Business Rules in the Payment Auth - Account and Payment Auth - Subscrib sections determine the host name, URL, merchant ID, public and private keys, and other parameters used by the PAS with a payment authorization vendor. They are specific to the vendor (Braintree, Cybersource etc.).
If you currently store credit cards in Circulation but are moving to a tokenized solution, see Circulation FAQ 105 for the steps involved in encrypting and vaulting your current numbers. Additional Circulation FAQs detail the steps needed to implement a specific solution, such as Braintree or viaWARP.
Note:
When moving to an off-site credit card environment, including the Hosted Payment Page, be sure you have a Credit Card Account record defined with a blank credit card type and associated GL account.
In some cases, a credit card vendor may not pass back a credit card type and there are not enough digits in the masked number to determine the credit card type (and hence the GL account to be used).
This can also happen when importing vaulted payments via Lockbox Processing. See Credit Card Account in the Setup Manual for more information.
Circulation’s HOP uses the credit card tokenization process described above for credit card authorization and storage, but it also removes data entry of credit card information from Circulation. It does this by displaying a separate third party browser window when entering a payment in Customer Service, Batch Payments or iServices. An example of a HOP is shown below.
Once the credit card information is entered, the rest of the payment can be completed within Circulation or iServices. A token (and typically a masked credit card number) is returned to Circulation, as with other tokenized solutions. The architecture of the HOP is illustrated below.
If using a HOP solution, the Business Rule Which off-site credit card storage and authorization service do you use? (Pymt Auth - General) must be set to “Hosted Page”. The HOP vendor is configured by another Business Rule in the same section, Which hosted page credit card authorization service do you use?
As with tokenization, additional Business Rules in the Payment Auth - Account and Payment Auth - Subscrib sections determine settings for specific hosted page vendors. Circulation FAQs are available for most vendors, detailing the specific setup needed.
