IVR Payments With Twilio

This document is to give a high level overview of Twilio <Pay> to enable IVR Payments. Twilio has samples, how to videos on Twilio Flow, and other Twilio tools. Should there be any questions on Twilio Flow, <Pay> TwiML, configuring webhooks / RestAPIs in Twilio, please reach out to Twilio Support.

Twilio Links:

https://www.twilio.com/pay

(844) 814-4627


Prerequisite:

  • Have either a sandbox or production level merchant account with Base Commerce
  • Need to have the SDK credentials from the Developer tab in the Merchant Portal to be given as configuration input to Twilio <Pay>.

Note: Setting sandbox to "true" in Twilio, will make the SDK call's hit Base Commerce sandbox URL, meaning that Base Commerce production SDK credentials will not work with the Twilio <Pay> sandbox setting set to 'true' and vice versa.



Payment can be done in one of the following ways:

  • Use Twilio path to make a direct charge using caller provided Card / ACH details. No Base Commerce Token is created by Twilio.
  • Use Twilio path to have Twilio return a Base Commerce Token against the caller provided Card  / ACH details.
    • And then directly invoke payment to Base Commerce (not to Twilio) by making a ‘processBankCardTransaction’ or ‘processBankAccountTransaction’ SDK call to BaseX with the Base Commerce Token received from Twilio.


 

Process Flow:

  • Twilio provides webhooks / callbacks to Integrator's software (aka partner software). This is used by the Integrator software to (i) do proper housekeeping of Base Commerce Tokens and (ii) to manage payments. Every step of the process flow of any IVR call should be controlled and managed by using 'Twilio Flow'. 
  • A high level process flow would be something like the following:
    • A customer calls the IVR phone number.
    • Twilio Flow: A greeting and request for information is communicated by the IVR system to the customer. This will be as configured by the Integrator per their need in Twilio Flow. It is in here the Integrator can configure what all information needs to be taken as input from the caller.
    • Caller provides their 'customer ID' (or more information as was configured in the Twilio Flow)
      • Some merchants typically use the caller’s phone number as the ‘customer ID’ and skip the step for the caller to provide any merchant provided ‘customer ID’.  They use the caller’s phone number to identify the correct account in their system and store the reference to the payment. This makes their IVR call go faster, without the need for additional caller’s time to enter merchant provided ‘customer ID’ – e.g. ‘customer IDs’ that one can see in utility bills / healthcare bills / etc.
      • Some merchants prefer to have the callers provide their merchant assigned ‘customer ID’ as input – the one that was sent to them in their bill.
      • Some merchants also ask for additional inputs based on their business need, and configure Twilio Flow accordingly.
    • Twilio Flow: Twilio sends the information entered by the caller to Integrator's software as per webhook / RestAPI configured.
    • Twilio Flow: Twilio asks the caller for the payment instrument and payment details (Card / ACH).
    • Twilio Flow: As per the business need of the Integrator, configurations can be done in Twilio Flow to do one of two things.
      • Invoke payment in 1 step: Configure Twilio Flow to directly post a charge using the caller provided payment details. No Base Commerce Token is created. Twilio will return results of processing and the Base Commerce Transaction ID in the response to Integrator’s software via webhook / RestAPI. Some merchants use this for payments that will happen only once. When there is no recurring payment expected for that account.
      • Invoke payment in 2 steps: (i) Configure Twilio Flow to Tokenize the Card / Bank Account and receive Base Commerce Token in response. Integrator then saves it in their records against their 'customer ID', and after that, (ii) invokes payment directly to Base Commerce (not Twilio) by making a ‘processBankCardTransaction’ or ‘processBankAccountTransaction’ SDK call to BaseX with the Base Commerce Token received from Twilio.
    • Twilio Flow: The call is closed with desired automated response as configured in Twilio Flow.
  • The above is a generic approach. It can be customized as much as needed / necessary by the Integrator in Twilio Flow. For instance,
    • Integrator software may provide the amount due and have Twilio ‘say’ that to the caller during the call,
    • Provide options to the caller to make payments less/more than the due amount,
    • Once the caller has been identified by ‘customer ID’ or caller’s phone number – Integrator may check if there is already any saved payment information for that caller in their database. If so, Integrator may ask caller to confirm use of the stored payment information and then place a direct SDK call to BaseX to have the payment done,
    • The Integrator may also choose to create Base Commerce Tokens all the time. Regardless of whether the payment will be only one time or recurring,
    • etc.
  • What is important to note is that, managing the Base Commerce Tokens is the responsibility of the Integrator.
    • If the payment is deemed as one time,
      • [commonly preferred by merchants] and no token was created, instead a direct charge was done. Then there is no action needed when it comes to managing / housekeeping of tokens.
      • and Base Commerce Token was created for the one time payment. The responsibility lies on the Integrator to delete the Base Commerce Token by making a ‘deleteBankCard’ or ‘deleteBankAccount’ SDK call to BaseX with the token to be deleted.
    • If the payment is deemed as one of future recurring payments, the responsibility of saving the Base Commerce Token in Integrator's software system and using it in future payments fall on them. This will save the Integrator from having multiple Base Commerce Tokens for the same customer and Card/ACH combination.



Search