Genesys Voice Payment (CE08) for Genesys Engage on premises

From Genesys Documentation
Jump to: navigation, search
This topic is part of the manual Genesys Engage On-Premises Use Cases for version Current of Genesys Use Cases.
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:

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 in question 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 Secure payment capture using IVR enables phone-based sales and collections to increase revenue.
Reduced Deployment Costs Proven, PCI PA-DSS certified application reduces deployment time and cost.
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 Use of an approved application reduces the risk or penalties and fines for non-compliance.
*You can sort all use cases according to their stated benefits here: Sort by benefits

Summary

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 (which is 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 Genesys Engage on premises
  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 states 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 is either rejected or successful.
  9. If rejected, the customer can re-enter their card details until the maximum number of rejections is met, when 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) Scenario 2 - Agent Conference

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 Genesys Engage on premises
  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 states 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 is either 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 can also play dynamic information such as a transaction reference or order number.
  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 chapter 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 payment was unsuccessful
  • Number of times payment was attempted
  • Number of times a caller hung up within the payment application
  • Average duration of task per outcome

Historical Reporting

Intelligent Automation offers a suite of internal reports details below:

Dashboard

  • Application Overview
  • System Pulse
  • Real-time Graphs

Prebuilt Reports

  • Summary
  • Calls per Day
  • Calls by Time of Day
  • Block Results
  • Recognition Summary
  • Business Task Summary

Customer Journeys

  • See what’s important to callers
  • Monitor the impact of changes
  • Compare customer experience
  • Data Extracts (CSV format)
  • Call Details
  • Business Tasks
  • GUI Actions
  • Inbound SMS

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

Inbound

None None


General Assumptions

  • The use case is supported for Cloud, Premise and Platform as a Service (IVR PaaS) .
  • For IVR PaaS, Genesys Intelligent Automation is deployed on premise.
  • 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 GAAP and the backend systems in order to ensure the required data contract is met.
  • Genesys Intelligent Automation is a required sellable item.
  • 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, dates, 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 are DTMF 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.





Document Version

  • Version v 1.1.5 last updated November 8, 2022

Comments or questions about this documentation? Contact us for support!