Genesys Voice Payment (CE08) for PureConnect

https://all.docs.genesys.com/images-supersite/a/a0/CE27_-_genesys_co-browse_-_header_%282%29.png

Capture payments in your IVR

What's the challenge?

Customers expect convenience and demand data security. They want the option of phone payment with the assurance of cardholder protection. If you don't accept card transactions by phone, you lose money. And if you don't exceed data security standards, you put your customers — and your business — at risk.

What's the solution?

Ensure secure interactions with a PCI-compliant solution that protects credit card data submitted to your automated IVR system or to an agent. Protect against fraud and preserve trust while still providing a flexible customer experience.

Other offerings:

Genesys Cloud

Use Case Overview

Story and Business Context

This functional use case enables companies to use Payment Capture capabilities to provide PCI PA-DSS certified payments out-of-the-box (PCI PA-DSS = Payment Card Industry - Payment Application Data Security Standard). Dynamic treatment is applied so that only relevant questions for the card are asked. The use case can be deployed in fully automated or agent-initiated mode.

Use Case Benefits*

The following benefits are based on benchmark information captured from Genesys customers and may vary based on industry, lines of business or Genesys product line:

Use Case Benefits	Explanation
Improved Customer Experience	Offer customers the option of agent-assisted or fully automated phone payments.
Increased Revenue	Improve revenue collection through speed to market and established best practice
Reduced Deployment Costs	Lower cost of deployment by reducing deployment time versus traditional IVR builds through pre-built IVR application modules
Reduced Interaction Abandonment	Certain self-service tasks require a solid means of authentication. If a caller cannot be adequately identified, the call will likely end up waiting for an agent to be available.
Reduced Penalties and Fines	Reduce fraud related penalties by using a PA-DSS certified application

^*You can sort all use cases according to their stated benefits here: Sort by benefits

Summary

This use case provides the ability to quickly add a PA-DSS certified Payment Capture MicroApp^** to a call flow to capture payments. The Payment Capture Microapp integrates with a third-party payment gateway to complete the payment. The application includes automatic card type detection and applies appropriate rules for collection and validation of the card data. Payments can be agent-assisted or fully automated.

^**Microapps provide a range of capabilities whose functionality is both highly focused and task-based, thus enabling users to quickly get in, interact, and get out of it. In the personal and business spheres, end users clearly benefit from an application interface that is tailored to their specific use case.

Use Case Definition

Business Flow

(1) The following flow describes the use case from the perspective of the main actors, especially customers.

Business Flow Description

1. A customer is transferred to the payment application by another IVR application. (outside of the scope of this use case). The requested payment amount is transferred to the payment application.
2. The system checks whether the Customer has been identified. If not, the customer is routed to a separate application for Identification and verification. This functionality is covered by a separate use case,Genesys Customer Authentication (CE07) for PureConnect
3. If identification and verification succeeds, the customer moves to the next step. If not, the customer is transferred to an agent with context.
4. The system determines if the caller is to pay a predefined amount or if the caller is permitted to enter the amount they wish to pay. If the latter, the system then enables the customer to enter a payment amount. The system checks if the entered amount is within allowed values before proceeding. The system can also allow the caller to choose to pay the full amount.
5. A voice prompt is played to ask the customer to enter their card details. The following happens:
   • The customer enters their card number.
   • The system checks if it is a valid card number and what type of card it is (the list of allowed card types is configurable). Finally, depending on the type of card, the customer is requested to provide further details (such as expiration date and CVV code).
6. The system plays back the payment details and asks the caller to confirm so that the payment can be processed. The caller will state whether the details entered are correct or incorrect. The option to read back only the last 4 digits of the card number is configurable.
7. If the caller states that the payment details are incorrect, the system asks the caller which of the previously entered information (such as card number or expiration date) was incorrect. Based on the caller’s choice, the system asks for the information again before returning to the confirmation step.
8. If the caller states that the payment details are correct, the system accesses the payment gateway or CRM to process the payment. This will either be rejected or successful.
9. If rejected, the customer can re-enter their card details until the maximum number of rejections is met, then the Customer is transferred to an agent with context.
10. If the payment is successful, Genesys plays an appropriate announcement to the customer and at this point, dynamic information, such as a transaction reference or order number, can also be played.
11. The call transfers back and continues in the IVR application. The result of the payment is attached to the call for further processing.

Business Flow

(2) Agent Conference Scenario

Business Flow Description

1. A customer is transferred to the payment application by conference from an agent with DTMF (Dual Tone Multi Frequency) clamping enabled. The agent is part of the call. The requested payment amount is transferred to the payment application.
2. The system checks whether the Customer has been identified. If not, the customer is routed to a separate application for Identification and verification. This functionality is covered by a separate use case,Genesys Customer Authentication (CE07) for PureConnect.
3. If identification and verification succeeds, the customer moves to the next step. If not, the IVR is removed from the conference, and the customer and agent continue their conversation.
4. The system determines if the caller is to pay a predefined amount or if the caller is permitted to enter the amount they wish to pay. If the latter, the system then enables the customer to enter a payment amount. The system checks if the entered amount is within allowed values before proceeding. The system can also allow the caller to choose to pay the full amount.
5. A voice prompt is played to ask the customer to enter their card details. The following happens:
   • The customer enters their card number.
   • The system checks if it is a valid card number and what type of card it is (the list of allowed card types is configurable). Finally, depending on the type of card, the customer is requested to provide further details (such as expiration date and CVV code).
6. The system plays back the payment details and asks the caller to confirm so that the payment can be processed. The caller will state whether the details entered are correct or incorrect. The option to read back only the last 4 digits of the card number must be enabled as the agent is part of the conference.
7. If the caller states that the payment details are incorrect, the system asks the caller which of the previously entered information (such as card number or expiration date) was incorrect. Based on the caller’s choice, the system asks for the information again before returning to the confirmation step.
8. If the caller states that the payment details are correct, the system accesses the payment gateway or CRM to process the payment. This will either be rejected or successful.
9. If rejected, the customer can re-enter their card details until the maximum number of rejections is met, then the Customer is transferred to an agent with context.
10. If the payment is successful, Genesys plays an appropriate announcement to the customer and at this point, dynamic information, such as a transaction reference or order number, can also be played.
11. The IVR is removed from the conference and the customer and agent continue their conversation.The result of the payment is attached to the call for further processing

Business and Distribution Logic

Business Logic

This section describes the business rules that drive the decisions that the Genesys system makes within the payment capture application,such as how the business rules are configured.

Parameters to be passed to the payment application

The payment application requires the following parameters:

1. Customer or Account Identifier (mandatory)
2. Outstanding Balance or Payment Amount (mandatory)
3. Payment Merchant ID (optional)
4. Payment Reference (optional)
5. Call type Conference (required if payment attempt is agent-assisted)

Configuration Settings

The following parameters are configurable within the system:

• The minimum payment amount (required). For payment requests below this amount, there is an error flow where the customer is asked to enter the amount they want to pay.
• The maximum number of declined payments allowed before exiting the flow.
• The result to return when the maximum attempts are reached, possibly to send the call to an agent or initiate some other handling.
• The types of cards that are allowed for payment (such as Amex and Visa)
• The currency of the payment.

Distribution Logic

N/A

User Interface & Reporting


Agent UI

N/A

Reporting

Real-time Reporting

Available KPIs:

• Number of times the payment application was entered
• Number of times a payment was successful
• Number of times a paymentwas unsuccessful
• Number of times paymentwas attempted
• Number of times a caller hung up within the payment application
• Average duration of task per outcome

Historical Reporting

Available KPIs:

• Number of times the payment application was entered
• Number of times a paymentwas successful
• Number of times a paymentwas unsuccessful
• Number of times paymentwas attempted
• Number of times a caller hung up within the payment application
• Average duration of task per outcome

Customer-facing Considerations

Interdependencies

All required, alternate, and optional use cases are listed here, as well as any exceptions.

All of the following required:	At least one of the following required:	Optional	Exceptions
Self-Service and Automation Genesys Customer Authentication (CE07)	None	Inbound Genesys Call Routing (CE01) Genesys Personalized Routing (CE02)	None

General Assumptions

• The integration between Genesys Intelligent Automation and the payment gateway (or CRM or other system used to process the payment) is provided by the customer/partner. This is an XML over HTTP(S) interface which typically requires a small translation later between Genesys Intelligent Automation and the backend systems in order to ensure the required data contract is met.
• Certification of the full PCI environment is outside the scope of this use case.
• Audio prompts:
  • Genesys recommends that pre-recorded prompt recordings be used for any dynamic playback of information such as payment amounts, or order numbers, as this provides a higher quality caller experience than using text-to-speech.
  • Sellable item Concatenated Prompts Recordings is the preferred option.
  • TTS is optional for playback of prompts.
• Input modes:
  • If the agent initiates payment capture by conferencing the customer with the IVR, customer inputs areDTMF only. DTMF clamping is used to prevent the agent from hearing DTMF inputs.
  • If payment capture is initiated from IVR, customer inputs can be voice or DTMF.,

Genesys Intelligent Automation requires PureConnect Voice XML Interpreter Server, Certification of the full PCI environment is outside the scope of this use case, Customer will provide access to XML/HTTP(S) interface for integration to Payment Gateway

• Payment Gateway Integration occurs via http(s) post web-service.
• PCI compliancy is handled in Cloud.
• Use case may use DTMF or ASR.

Document Version

• Version v 1.0.2 last updated February 16, 2021