Form payment configuration

Accelerated Service Request Forms Administration - TCOPS integration

Configure payment

As a form editor, I need to be able to configure my form to accept payment so I can collect payment from my users.

Configuration information required includes:

• Source system GUID (default GUID key)

• Source system secret key (default ASRF's key)

• Cost calculator URL

• Payment system base URL

• Return URL (note: this is dynamically determined by ASRF)

Acceptance criteria:

• Payment integration may be enabled or disabled for any given form.

• When enabled and the Save changes button is pressed, the following errors:

  • All fields are mandatory

  • GUID must be a {X} character alpha-numeric value

  • Secret key must be a {X} character alpha-numeric value

  • The Cost calculator URL must be a valid URL (as per RFC 3986) and a maximum of 2000 characters each

  • The GUID and secret key combination is not valid

  • The Payment system base URL cannot be reached

• The default value for the source system GUID and secret key will be that used by Accelerated Service Request Forms

• The default value for the Payment system base URL will be that used by TCOPS in the same environment used by ASRF.

• A confirmation message will be displayed when payment configuration information is successfully saved.

• When payment configuration information is enabled with all necessary information entered, payment page flows will be enabled for the form including the request summary, and request confirmation screens.

high

Inline help for payment configuration

As a form editor, I need to be able to access additional help resources explaining what the configuration information is and where to get it.

Acceptance criteria:

• A definition and explanation of where to get the following information will be available:

  • Source system GUID (default GUID key)

  • Source system secret key (default ASRF's key)

  • Cost calculator

  • Payment system base URL

• Dialog can be dismissed using the button or close icon.

LOW

Map payment system fields to form fields

As a form editor, I need to be able to link form fields to payment fields so that the necessary client information is passed to the payment system.

Tombstone information collected includes:

• Name

• Email

• Phone number

• Address (line 1)

• City

• Province

• Postal code

• Country

Acceptance criteria:

• For each mapping, an auto-complete will match in the language of the user to either:

  • Custom variables defined within the form

  • Names of form fields added to a form

• Error:

  • An error will be displayed if the text entered for any mapping field does not match a custom variable or form name.

high

Mapping of multiple fields to a payment field (such as a first name, last name, and business to the customer payment field) would be supported via custom variables initially.

Separate feature could introduced if this becomes more commonplace.

Validate payment configuration

As a form editor, I need to be informed if my form is missing any information that the payment system needs to process my payment when I publish my form so I can make the necessary corrections.

Acceptance criteria:

• An error message will be displayed if:

  • All tombstone information fields are not mapped to a form field

  • The form field lengths exceed the maximum allowable length for the payment system

  • The form field types do not match the payment system expected types (string, number).

  • The Payment system base URL cannot be reached

Medium

Accelerated Service Request Forms - Portal

Support payment for request summaries

As a client, I should be able to review my request to make any corrections before I make a payment.

Acceptance criteria:

• In the stepper, when payment is enabled for the form, the second last step on any given form is “Review request”, while the last step is “Payment”

• When payment is enabled for a form, the request summary screen action will be Proceed to payment

high

View receipt on request confirmation screen

As a client, after I have paid for my request, I should be able to view and print the payment receipt as proof of payment.

Acceptance criteria:

• Receipt information will include:

  • Customer name

  • Transaction total

  • Transaction type

  • Date/time

  • Transaction amount

  • Order number

  • Card number (masked)

  • Card type

  • Response/ISO code

  • Reference number

  • Authorization code

  • Receipt number

Medium

Display errors with TCOPS

As a client, if I encounter any problems within the payment system, I should be informed what the problem is and resubmit my request if it’s possible to do so.

Acceptance criteria:

• At any point during the transaction or when on the Moneris processing pages, if an error occurs, the user should be redirected back to the request summary page with a message indicating what the problem was.

• The user should be able to retry their payment by selecting the Proceed to payment button.

high

Display outage with TCOPS before payment

As a client, I should be informed if the payment service is not working before I enter my request, and/or immediately before trying to pay for my request.

Acceptance criteria:

• An error should be displayed when the service is unavailable when:

  • On the request summary page

Medium

Display outage with TCOPS before starting the request

As a client, I should be informed if the payment service is not working before I enter my request, and/or immediately before trying to pay for my request.

Acceptance criteria:

• An error should be displayed when the service is unavailable when:

  • Initiating the request

LOW