Embedded Files
We've moved! Visit and bookmark catalyst.avaya.cx to see current content. This site is outdated.
This covers how to set up credit card processing in Console.
In this article
In this article
Overview
Overview
With workflows, you can create tools and automations in a no-code builder to streamline aspects of your business. One common use case for workflows is for taking credit card payments over the phone.
There are default workflow templates that you can use to quickly copy, configure, and connect them to your queue so that your queue users can easily process credit card payments over the phone.
Default workflow templates make it easier for you to accept credit card payments over the phone.
This tutorial will show you how to configure the credit card template workflows. There are three overarching steps to this tutorial:
Copying the workflow templates
Configuring the workflows
Connecting the workflows
Follow along with this tutorial to learn how to set up credit card processing with workflows.
Steps
Steps
Step 1: Copying the workflow templates
Step 1: Copying the workflow templates
First, we need to make copies of the workflow template. Once we’ve made copies, we’ll be able to make edits and configure them to our needs.
To find the templates, first we’ll navigate to the Workflows workspace. Then, we’ll click the Template Workflows folder.
After clicking the Template Workflows folder, we’ll need to locate the two workflow templates to copy. They are called:
Automated Payment Main Workflow Embedded
Secure Sub Automated Payment
Continue reading the subsections below to learn how to locate and copy these workflows.
Automated Payment Main Workflow Embedded workflow template
You can find the Automated Payment Main Workflow Embedded workflow at the following folder path:
Workflows > Template Workflows > Automated Payment Main Workflow Embedded
Follow the steps below to make a copy of the template:
Click the workflow to open it.
Once opened, click the vertical tri-dot icon in the top-right corner of the screen.
Click Copy.
Provide a new name for the workflow.
For the purposes of this tutorial, we’ll call it CC Parent.
We’re naming it CC Parent because its main job is to set up a phone call for credit card processing and to then run a subroutine workflow, also called a child workflow.
Keep the category as it is.
Click Save.
After you click Save, an exact copy of the template workflow will appear in the workflow workspace.
Secure Sub Automated Payment workflow template
You can find the Secure Sub Automated Payment workflow template at the following folder path:
Workflows >Template Workflows > Subroutines > Secure Sub Automated Payment
Follow the steps below to make a copy of the template:
Click the workflow to open it.
Once opened, click the vertical tri-dot icon in the top-right corner of the screen.
Click Copy.
Provide a new name for the workflow.
For the purposes of this tutorial, we’ll call it CC Child.
We’re naming it CC Child because it’s a subroutine. Its main job is processing credit card transactions. It doesn’t run on its own; it runs when invoked by the CC Parent workflow.
Keep the category as it is.
Click Save.
After you click Save, an exact copy of the template workflow will appear in the main workflows workspace. Your workflow workspace should look something like the screenshot below:
Step 2: Configuring the new workflows
Step 2: Configuring the new workflows
Now that we have copies of the two workflow templates, let's take a look at them and configure them.
Child workflow
First, let’s take a look at the CC Child workflow.
Remember that the child workflow is a subroutine of the parent workflow. This means that, when the parent workflow runs (CC Parent), it eventually arrives at the Subroutine module, where it then triggers the subroutine (CC Child) workflow to run.
At a glance, the CC Child workflow may seem complicated, but we’ll break it down into its components so it’s easier to understand.
The bulk of the logic for credit card processing is contained in the column of Say + Gather and Say + Intent modules in the middle of the workflow (see screenshot below). The purpose of these modules is to gather and confirm the customer’s credit card information.
The other modules handle what happens when the information gathering process fails. For example, if the customer provides an invalid credit card number, it loops back to allow the customer to provide the number again.
The credit card processing logic mostly takes place in the outlined area.
Follow the labeled screenshots and corresponding descriptions below to understand the main logic of the workflow.
1. Say + Gather - Gather CC: This prompts the customer to input their credit card number via DTMF. (It saves it as a variable called creditCardNumber. )
2. Say + Intent - Repeat Card: This repeats the card number back to the customer.
3. Trigger - Yes - 1: The customer indicates that the credit card number is correct.
4. Set Variable: The last four digits of the credit card number are saved as a separate variable.
5. Say + Gather - Gather CVV: This prompts the customer to input their credit card CVV via DTMF. (It saves it as a variable called cvv.)
6. Say + Intent - Repeat CVV: This repeats the CVV back to the customer.
7. Trigger - Yes - 1: The customer indicates that the CVV is correct.
8. Say + Gather - Gather Exp Month: This prompts the customer to input their credit card expiration month via DTMF. (It saves it as a variable called expMonth.)
9. Say + Intent - Repeat Month: This repeats the month back to the customer.
10. Trigger - Yes - 1: The customer indicates that the expiration month is correct.
11. Say + Gather - Gather Exp Year: This prompts the customer to input their credit card expiration year via DTMF. (It saves it as a variable called expYear.)
12. Say + Intent - Repeat Year: This repeats the year back to the customer.)
13. Trigger - Yes - 1: The customer indicates that the expiration year is correct.
14. Webhook - Webhook to CC Payment Provider - This is where the information is sent to your credit card payment processor via their API.
The exact configuration of this module will depend on your credit card payment processor.
Refer to your credit card payment processor’s API specifications for more information.
For more information about the webhook module in general, see: Overview: Webhook workflow module (Console).
15. Say - Card Create - A message is read to the customer thanking them for inputting their credit card information.
Note: We recommend that a developer or someone familiar with APIs configure and test your webhook connection with your credit card processor.
Once you’ve configured the webhook module, publish the workflow. Once published, we’ll be able to hook it up to the CC Parent workflow.
Parent workflow
Next, let’s take a look at the CC Parent workflow.
The CC Parent workflow does the following (when successful):
Start: The workflow starts. This workflow is designed to run as an embedded workflow within an interaction.
Update Interaction: The current interaction is placed on hold.
Create Call: A separate phone call is made to the customer. This is the phone call where the credit card details will be gathered.
Subroutine: The subroutine runs. This is where the CC Child workflow runs.
Return: This is where the subroutine ends and the workflow continues.
Note that, if there’s an error anywhere (in making the phone call or in the subroutine itself), the workflow ends by hanging up the call and giving the queue user any error message from the credit card payment process.
The only configuration you need to make to the CC Parent workflow is for the Subroutine module.
Steps to configure subroutine module:
Double-click the Subroutine module.
2. In the right sidebar, search for and select the CC Child workflow.
3. In the Workflow Version selector, select Current.
4. Click the Save button to save the module.
Once you’ve configured the subroutine module, publish the workflow. Once published, we’ll be able to connect the workflow to a queue.
Step 3: Connecting the new workflows
Step 3: Connecting the new workflows
The last step is to connect the parent workflow to a queue as an embedded workflow.
This means that, when a queue user runs the embedded workflow from within an interaction, the parent workflow will run and trigger the child workflow to gather the credit card information and send it to the credit card processor.
Follow the instructions in this article that covers linking an embedded workflow to a queue. Make sure to set the CC Parent workflow as the embedded workflow.
Once you’ve linked the embedded workflow to a queue, queue users will be able to run the workflow to process credit card payments over the phone.
Page updated
Report abuse