The Payment Express IVR provides the ability for a Payment Express customer to take phone based payments inside of Payment Express' PCI compliant environment. The call scripts used are configurable and may be varied on a per customer basis. The purpose of this page is to show the "off the shelf" call script and to provide a starting point for merchants to design their own call scripts. Merchants wishing to customise their call script will need to consult their allocated Project Manager at Payment Express to verify their requirements are able to be met.
|A01||When transferring a call to the Payment Express IVR the merchants system will fully de-trombone the call.||Failure to do so will mean DTMF tones pass through the merchants system and therefore leave them in scope for PCI requirements|
|A02||DTMF tones will be received by the Payment Express||system out of band.|
This section documents the Call script process flow of the standard (off the shelf Payment Express IVR)
Alterations to the call script may be made as necessary; however alterations will impact on development timeframes. It is
expected that in most cases merchants will require a way of matching or importing a transaction into their system. This
may be achieved my providing a reference for a transaction that is returned in the transaction result. This could be a
customer Id or perhaps an invoice number. In this scenario we recommend altering '1.0 Entry point' to give a general
overview of the process flow and insert a new 1.0 similar to '1.1 Capture Amount' an example is below.
Each of the Prompts in the call script will require 1 or more audio files to be played. It is expected that the Payment Express customer requesting the IVR will supply these files named accordingly. The Call script field below is a guide and the customer may choose to alter wording for a given file provided this alteration does not influence the expected behaviour of the
cardholder at the given prompt. Alternatively a text to speech option is available for customers not wishing to provide their own custom voice files. It is recommended that files have consistent quiet space at beginning and end so that when numbers are being played back to cardholders the speech pattern is consistent.
The audio file format should be 8 bit, 8 kHz, u-low
|Prompt||File Name||Call Script|
|1.0-1||1.0-1.wav||Welcome to xxx please press # to enter your payment details.|
|1.1-1||1.1-1.wav||Please enter the amount you wish to pay and press the # key.|
|1.1-2||1.1-2.wav||The amount you have entered is|
|1.1-3||1.1-3.wav||If this is correct press the # key. To change the payment amount press the * key.|
|1.1-4||1.1-4.wav||The transaction amount is invalid.|
|1.2-1||1.2-1.wav||Please enter your credit card number and press the # key.|
|1.2-2||1.2-2.wav||The number you have entered is|
|1.2-3||1.2-3.wav||If this is correct press the # key. To re-enter the card number press the * key.|
|1.2-4||1.2-4.wav||The card number is invalid.|
|1.3-1||1.3-1.wav||Please enter the card’s expiry date in month month year year format and press the # key.|
|1.3-2||1.3-2.wav||The expiry date entered is|
|1.3-3||1.3-3.wav||If this is correct press the # key. To re-enter the expiry date press the * key.|
|1.3-4||1.3-4.wav||The expiry date is invalid.|
|1.4-1||1.4-1.wav||Please enter your 3 digit card security code and press the # key. This is usually located on the back of your card.|
|1.4-1A||1.4-1A.wav||Please enter your 4 digit card security code and press the # key|
|1.4-2||1.4-2.wav||The card security code entered is|
|1.4-3||1.4-3.wav||If this is correct press the # key. To re-enter the card security code press the * key.|
|1.4-4||1.4-4.wav||The card security code is invalid.|
|1.5-1||1.5-1.wav||Please wait while your transaction is processed.|
|1.5-2||1.5-2.wav||Thank you your transaction has been approved.|
|1.5-3||1.5-3.wav||I’m sorry your transaction has been declined.|
|1.5-4||1.5-4.wav||Press * to try another card or hang up to exit.|
|1.6-1||1.6-1.wav||Thank you for calling goodbye|
|1.6-2||1.6-2.wav||Your credit card has not been charged.|
|Prompt||File Name||Call Script|
The functionality of the IVR call flow may be customised to suit your needs on a case by case basis. Additional charges
may apply, please contact one of our Sales representatives (email@example.com) for more information.
Preferably the low level prompts above would not be changed but the need may arise to obtain additional input parameters from the cardholder. It is suggested that any additional prompts appear before the prompts to capture card
information. If this is required please document the process flow as above and supply to your Payment Express Project Manager (once available and project has been initiated) for verification.
One common requirement is to have a merchant provided unique identifier for a transaction. The call script can be structured to have this variable passed in by the merchants system before transferring the call thus making this step
invisible to the cardholder. Alternatively a prompt may be added to ask the cardholder to provide the reference (perhaps an invoice Id).
The IVR on completion of its call script processes transactions via Payment Express' PxPost interface. As such it is possible to customise the PxPost
IVR transactions take place on the Payment Express' system; therefore the need arises to have mechanisms that will allow the Merchants system to become aware of transactions that have been processed. There are various options available to achieve this.
A user account to log into the Payment Express system to view transactions is made available by default for all Payment Express customers. Reports may also be generated and obtained through this interface.
A Report that contains transactions processed on a merchant account may be generated and sent on a periodic basis (usually daily). The method of delivery is optional between sFTP and email. Please contact one of our Sales representatives (firstname.lastname@example.org) for more information.
A real-time soap request may be generated with the transaction details and sent to a web server hosted by the merchant. This option allows a merchant to update their system in real time with transaction outcomes. It requires the merchant to develop a SOAP web server that conforms to a specification provided by Payment Express in the WSDL below.
The IVR can accept / allow the cardholder to input buttons over the top of the audio files. However, only the last audio file in a prompt (that contains a sequence of audio files) may be skipped by user input.
A test IVR will be made available for the merchant to perform validation that the IVR meets their agreed upon requirements. Once the Merchant has signed off the IVR requirements they may request the code be deployed into the production environment. The environment will remain available for 5 working days following the production deployment. After which it may be taken down and made available to other merchants waiting for development testing.
|Assumption||A condition not certain to happen outside the control of the project and necessary for the project or solution to be successful.|
|Constraint||A condition that limits the project or solution is outside the control of the project and needs to be managed around.|
|Dependency||A relationship between conditions where one cannot start or finish until another starts or finishes.|
|Recovery Point Objective||This describes the acceptable amount of data loss measured in time.|
|Recovery Time Objective||This describes the duration of time and a service level within which a business process must be restored after a disaster (or disruption) in order to avoid unacceptable consequences associated with a break in business continuity.|
|SLC||Solution Life Cycle|
|API||Application Programming Interface|
|BAU||"Business As Usual"|
|EULA||End User License Agreement|
|PX Pay||Payment Express Hosted Payments Package|
|PX Post||Merchant Hosted Payments Package|
|3-D Secure||3 Domains Secure. E-Commerce environment including Acquirers/Merchants Issuers/Cardholders and Card Schemes. 3-D Secure adds an authentication step for Internet txns where the card holder is redirected to his/her card issuing bank's 3-D Secure page to enter a password or special code. It is currently supported by only some acquirers and only some card issuing banks.|
|AAV||Accountholder Authentication Value. Unique reference generated by MasterCard and Maestro card issuers to prove authentication took place.|
|CAVV||Cardholder Authentication Value. Supplied by card issuer as part of a successful 3D Secure authentication.|
|BIN||Bank Identification Number. The first six digits of the number of various financial cards such as Visa or Mastercard. These digits identify which organization issued it.|
|CVC/CVV||Stands for "Card Verification Code"/"Card Verification Value" it is the 3-digit number on the back of credit cards used for security purposes.|
|PCI-DSS||Payment Card Industry - Data Security Standards.|
|ECI||When processing Internet transactions the Electronic Commerce Indicator (ECI) must be included on the payment transaction message format to show that the transaction originated form an Internet source. If an ECI is sent with values of 5 6 or 7 the transactions are noted as a secure ECI transaction and must be processing card data securely. If transactions are submitted with an ECI value of 8 or 9 the card data is in a non-secure format and the transaction will incur a high MSF (Merchant Service Fee).|
|MPI||Merchant plug-in. Software that facilitates the 3D Secure process (sending and receiving of PAReq/PARes) through to Visa/MasterCard.|
|FPRN||Fail-Proof Result Notification|