Generic Gateways
- Persia Xenopoulou (Deactivated)
On this page
Overview
A payment gateway is a service provided by a third-party system that authorises credit card or direct payment processing for e-business. Gateways are referred to as 'generic' when they only support the partial handling of online payments. Generic gateways create payment requests that can be further processed by CRM.COM WEB APIs. The APIs extract the requests and update them once the payments are handled by the gateway.
Payment gateways functionality
- Handling of payments between a company and its customers.
- Refund of online customer accounts when payments are cancelled or a refund is executed in CRM.COM.
- Redemption of instant spend awards earned through participation in reward programs.
- Gateway runs create payment requests for unsettled bills or for topping up wallets.
- Gateway runs identify the transactions that should be handled by the gateway by using the CRM.COM payment or refund transaction method and create respective requests.
Payment gateway requests can be updated through WEB APIs. Refer to Integrating Payment Systems for comprehensive instructions on how to integrate a payment gateway with CRM.COM.
Setting Up Generic Gateways
Payment gateway provider
Payment gateway providers are used to set up triggers for payment and refund requests.
Provider fields
The table describes the sections of the Generic Provider Data Entry page and explains how the fields in the page are used.
Mandatory
Configurable
Main Information | |
|---|---|
| |
Supported Attributes Defines attributes that must be used by payments and refunds to be processed by the specific gateway. | |
| | Add payment methods that when defined on a CRM.COM payment will trigger the creation of a request to the gateway. The same method of payment cannot be included in more than one payment gateway provider. |
Add refund methods that when defined on a CRM.COM refund will trigger the creation of a request to the gateway. The same method of refund cannot be included in more than one payment gateway provider. | |
A list of currencies supported by the gateway. It is possible to support all currencies or specific ones. An account payment preference associated with the gateway can only be selected (when creating a payment or refund transaction ) if the currency of the accounts receivable is included in the list of currencies supported by the gateway. A payment or refund method is selected when a payment or refund transaction is created. If the method is related to a generic payment gateway but the currency of the accounts receivable is not included in the gateway's list of supported currencies, then the account payment preference field will not be available. | |
When a payment made from an online customer account is cancelled in CRM.COM, the account is refunded. Define the Payment Cancellation Types that will trigger the submission of a payment cancellation to the gateway when posted. | |
Automation Settings | |
| Payments | Define default values for the attributes below, for use by each gateway during automatic payment runs (to settle bills or top-up wallets):
Default Notes |
Related configuration areas
Mandatory modules must be configured for the Generic Gateways module to work.
Optional modules may be configured for the module to operate at its full capacity.
| Manual Link | Area | Description | Configuration Type |
|---|---|---|---|
| Financial Transactions | Payment Type | Create the type of payment that will be created and processed by the gateway when automated processes such as bill payments and wallet top-ups are triggered. | Mandatory |
| Financial Transactions | Payment Cancellation Type | Create the types of payment cancellation that will trigger a payment cancellation gateway request. | Optional |
| Financial Transactions | Refund Type | Create the refund type used to create refunds. | Mandatory |
| Financial Transactions | Payment Methods | Create the methods of payment that will trigger gateway requests and then add them to the payment gateway provider. A method should be added in the allowed payment type methods to be available. | Mandatory |
| Financial Transactions | Refund Methods | Create the methods of refund that will trigger gateway requests and then add them to the payment gateway provider. A method should be added in the allowed refund type methods to be available. | Optional |
| Accounts Receivable | Payment Preference | Create the payment preference that is associated with the payment gateway. The preference should be set on the customer's accounts receivable together with additional information, such as online account credentials. | Mandatory |
| Wallets | Wallet Definitions | Set the rules that will be used to top up the wallets of customers through payment gateway requests. | Optional |
| Platform | Currencies | Define the currencies that will be supported by the gateway provider. A currency will also be defined as supported for each accounts receivable. | Mandatory |
| Rewards | Participating Rewards Merchants | Enable back-end reduction and set the refund method that should be used to refund payment gateway accounts. | Optional |
Using Generic Gateways
Finance > Payment Gateways > Generic Gateways > Manage Payment Gateway Requests
Integration with a payment gateway enables the handling of payment and refund requests between CRM.COM and online accounts belonging to customers.
Requests are triggered when payments, refunds or payment cancellations, using methods and types supported by the provider, are manually created in the financial transactions Data Entry page.
Payment gateway runs also create requests to:
- Settle outstanding bills, subject to the payment preferences of the account.
- Top up wallets that fund prepaid subscriptions when the wallet's threshold (set in CRM.COM) is crossed.
Payment gateway requests are further processed using WEB APIs and sent to the gateway. The life cycle state of the request is updated to 'Posted' or 'Rejected', accordingly.
All requests are available through a dedicated Summary page. Requests cannot be processed further and do not have a Data Entry page.
Payment gateway requests fields
The table describes the fields of the Gateway Summary page and explains how the fields are used.
Number | An auto-generated unique ID for each gateway request. |
|---|---|
| Payment Gateway Provider | Processes the gateway request |
| Type | 'Payment', 'Refund' or 'Payment Cancellation'. |
| Payment Gateway Run | The processing run that automatically created the request. |
| Payment | The number of the refund created in CRM.COM. |
| Payment Cancellation | The number of the payment cancellation created in CRM.COM; applies to generic payment providers only. |
| Payment Gateway Reference Number | The number provided by the payment gateway. The number is assigned when a request is 'Posted' or 'Rejected' and therefore not available for requests in other life cycle states. |
| Account Number | The number of the accounts receivable associated with the payment gateway request. |
| Paid Bill | The number of the bill that was paid or is intended to be paid. |
| Topped-up Wallet | The number of the wallet that was topped-up.
|
| Execution Date | The date on which the request was posted or rejected by the payment gateway provider. |
| Life Cycle State | Requests can be in one of the following states:
'Pending' or 'Under Processing' requests can be rejected or posted through WEB APIs. |
| Error Code | Received by the payment gateway provider, in case of error. |
Creating and processing generic gateway requests
Validations take place before an action is initiated (prerequisite) or after it is submitted (postcondition).
Creating generic gateway requests through payment gateway runs
Finance > Payment Gateways > Perform Automatic Payment Runs
Payment gateway requests are created when payments, refunds or payment cancellations (associated with the gateway through their type or method) are created in CRM.COM.
Additionally, automatic payment runs identify bills to be paid or wallets that should be automatically topped up through a payment gateway.
Bill Payment: Unsettled bills can be paid through the payment gateway before they are due, sparing the customer of the anxiety associated with its timely payment. The process is similar to a direct debit transaction. The automatic payment run identifies bills that meet predefined criteria and creates the respective payment requests.
Wallet top-up: Requests can be used to automatically top-up the wallet of prepaid subscribers from their online accounts, ensuring that the service is not interrupted. The system detects when the wallet balance crosses a predetermined threshold and automatically creates a top-up request through the customer's gateway.
To enable wallet top-up, configure the top-up rules in the active wallet definition. Define the threshold that triggers top-up, the amount to credit the wallet and frequency at which the balance should be checked. Once the system is set up, the automatic payment run will create payment requests for wallets that meet predefined criteria.
To create an automatic payment run, navigate to Perform Automatic Payment Runs and create a NEW definition. Select a gateway provider, supply scheduling settings and SAVE. Once completed SUBMIT the run to create the requests.
Automatic Payment Run Definition fields
Mandatory
Configurable
| Main Information | |
|---|---|
The Only 'Effective' | |
| Process Runs | |
| Process Run Information related to processed requests. |
Additional information
| Bill Prerequisites |
| |
|---|---|---|
| Wallet Prerequisites |
| |
| Postconditions | If a 'Pending' or 'Under Processing' payment request already exists for the wallet identified for a top-up or for the bill to be paid, then the request will not be created (to avoid payment request duplication). | |
Modifying a generic gateway request
Through WEB APIs the life cycle state of a request can be updated to one of the following states:
- Under Processing
- Posted
- Rejected
Refer to Integrating Payment Systems for comprehensive instructions on how to integrate CRM.COM with a payment gateway system using WEB API.
Applying business flows on generic gateways
Refunding cancelled payments
Customers can be refunded if payments that were successfully completed through a gateway are cancelled in CRM.COM. A request is created and handled by the gateway to return the funds from the merchant to the customer.
Refunding rewards participants for spending awards (back-end reduction)
Rewards participants can earn awards from a purchase and use them for an instant discount. This can be handled by the system as such:
- Front-end reduction: The customer can get the discounted price from the point of sale (POS)
OR - Back-end reduction: The customer pays the regular price at the POS and is refunded the discount amount by CRM.COM through a payment gateway. Funds are returned to the customer's bank or online account (e.g., PayPal). In order to apply this option, a refund method that will trigger the refund in the gateway provider must be selected and the back-end reduction settings of the merchant must be configured.
Refer to Multi-partner Rewards Platform for set up instructions and for more information on back-end reduction.
Communicating generic gateway information
Generic gateway information, such as payment gateway requests can be communicated through the communications Data Entry page. You can use tags (text that is automatically replaced by values specific to selected records) related to generic gateways when creating communications. Tags can be selected by typing '#'. Refer to the Communications manual for a comprehensive list of generic gateways tags.
Configure CRM.COM to automatically inform customers when payments or refunds are effected by a payment gateway. For information on setting this up, refer to event-based Communications.
Generic Gateway Analytics
Segmenting generic gateways
Payment gateway requests with common business characteristics can be grouped together. The resulting segments can be used in system business processes, such as identifying customers or for simple statistical calculations. For more information on segmentation and how you can create generic gateway lists refer to Segmentation.
Generic Gateways Business Examples
Handling payments online through a payment gateway
Scenario
Company ZX has its merchant account registered with Zulu, a gateway that handles credit card payments. ZX customers that wish to pay with a credit card must also have a Zulu account. Zulu is updated with the payments made in CRM.COM on an hourly basis and replies to CRM.COM with a success or error message. Payments that should be handled by Zulu are the following:
- Manual payments (made by customers over the phone)
- Automatic bill payments (for unsettled bills)
- Automatic wallet top-up (€20 when the wallet balance drops to €0).
Solution
Configuration
- Create a Payment Method for Zulu (for creating a new Payment in CRM.COM).
- Create a Payment Type for Zulu and add the payment method above as 'allowed' (for creating a new payment in CRM.COM).
- Create a Payment Preference for Zulu:
- Configure a payment preference for Zulu and enable the medium identifier field.
- Enable the Zulu payment preference in the customer's accounts receivable.
- Save the credit card number in the Zulu payment preference identifier field.
- Create a generic gateway provider for Zulu, entering the Zulu payment method under 'Supported Attributes'; Set the Zulu payment method and type as defaults.
- Create an accounts receivable classification to be used in wallet definition top-up rules.
- Configure wallet definitions top-up rules to credit the wallet with €20 every time its balance drops to €0.
- Configure automatic payment run definitions to create payment requests for unsettled bills and for wallets that need a top-up. Schedule execution on an hourly basis.
User Process
- When a user registers an accounts receivable containing Zulu gateway details, select the Zulu payment preference and provide the customer's credit card number as an identifier.
- Set the account classification configured in the wallet top-up rules.
- Select Zulu payment method and respective presentment preference when a new payment is created. The payment will be created with a 'Pending Verification' life cycle state.
Technical staff should use CRM.COM WEB APIs to collect pending payment requests and forward them to Zulu, on an hourly basis, and update CRM.COM with the respective responses.
Use GET payment_gateway_requests/get_pending to update Zulu. Once Zulu responds, CRM.COM should be updated accordingly, using the following WEB APIs:
- Use POST payment_gateway_requests/bulk/post to post the 'Pending Verification' payments which have been successfully completed in Zulu.
- Use POST payment_gateway_requests/bulk/reject to reject the 'Pending Verification' payments which have not been successfully completed in Zulu.
Refunding reward participant payment gateway accounts for back-end reductions
Scenario
Company ZX would like to handle auto-spend customer returns through Zulu.
A rewards participant makes a discounted purchase by using an award. The customer pays the regular price at the point of sale and the awarded money is returned to their Zulu account (back-end reduction).
Solution
Configuration
- Configure the refund method that will be used for back-end reductions through Zulu.
- Configure a refund transaction type and add the refund method as 'allowed'.
- Configure the Zulu provider and select the allowed refund method that will be logged by back-end reduction.
- Configure automatic payment run definitions that will refund the Zulu account of reward participants.
- Enable the back-end reduction method and define the refund type and method that will be used to refund the Zulu account of reward participants.
- Configure an accounts receivable payment preference and relate it to Zulu.
User Process
Accounts Receivable: When a user registers an accounts receivable containing Zulu gateway details, select the Zulu payment preference and provide the customer's credit card number as an identifier.
Technical staff should use CRM.COM WEB APIs to collect pending payment requests and forward them to Zulu, on an hourly basis, and update CRM.COM with the respective responses.
Use GET payment_gateway_requests/get_pending to update Zulu. Once Zulu responds, CRM.COM should be updated accordingly, using the following WEB APIs:
- Use POST payment_gateway_requests/bulk/post to post the 'Pending Verification' payments which have been successfully completed in Zulu.
- Use POST payment_gateway_requests/bulk/reject to reject the 'Pending Verification' payments which have not been successfully completed in Zulu.
Notes
- If you are using a previous release, view CRM.COM Release Changes.
- Use the WEB API to create and manage gateways from an external system, such as a customer portal. Refer to the Payment Gateway WEB API for a comprehensive list of available actions. Refer to Integrating Payment Systems for a description on how to integrate a payment system with CRM.COM.
Glossary
| CRM.COM Term | Description |
|---|---|
| Wallet | A customer account whose credit balance is used to fund transactions within CRM.COM. |
| Prepaid Subscription | A selection of customer services that are renewed automatically, billed on a recurring, usage or one-time basis and paid in advance. Prepaid subscriptions are funded directly from a subscriber's wallet. |
| Bill | An itemized account of the cost of physical goods supplied, termed, usage and one-time services rendered and Subscription or Job expenses. Bills consist of the invoices and credit notes created by the system for an account during the period the bill covers. |
| Accounts Receivable | A ledger of the financial transactions carried out between a company and its customers, such as invoices and payments. The accounts receivable keeps a running balance of debits and credits and displays the amount a company is owed in exchange for goods supplied and services rendered. |
| Rewards Participant | A customer who can be awarded offers provided through the rewards program. |
| Rewards Participating Merchant | A merchant that collaborate with the rewards platform. |
| Auto-spend | An instant discount obtained by using an award earned from the actual purchase. |
| Back-end reduction | Awarded money returned to the customer's account as a discount, following a purchase that was paid in full at the point of sale. |