Processing payment transactions using the Credit Card Field

Processing a credit card payment is a very important and sensitive part of an application. There are many ways to receive a payment from a customer including PayPal fields with the Express Checkout Enterprise service bus, Amazon Flexable Payment Service actions, Credit Card fields combined with Credit Card Payment actions, and Credit Card fields using the transaction amount setting. This article will focus on the last option.

Commonly a credit card field using the transaction amount setting is best for payment flows that result in a single one time payment where the end user is not expected to make further payments using that payment information.

To use this feature you will need to signup for a Braintree account for production keys and signup for a Braintree sandbox account for development and testing keys. You will then have to create short text fields to store the keys in your application.

Because the transaction amount setting requires the value of the transaction amount to be stored in a field prior to rendering the credit card field it is recommended that all interactions that may change the value of the transaction amount be done on a page prior to displaying the page rendering the credit card field. If the end user is given the ability to perform an action that will change the value of the transaction on the same page as the credit card field then it will be necessary to refresh the form that contains the credit card field resulting in the loss any information that the user may have typed in the credit card field. Conversely if the form is not refreshed then the amount submitted for payment will be incorrect and result in either under or over charging the end user. This is sub optimal user interaction that could cause an end user to abandon the payment flow or initiate a charge back against the transaction.

Fig. 1: The cart page allows the user to remove or continue shopping before the payment page is displayed.

After the transaction amount is finalized a page containing a summary of the charge and the credit card field should be displayed. Because the field will save the transaction id on the same record as the payment information it is recommended that one record be used for each new transaction. A Table called payment transaction or payment receipt containing at minimum the total charge amount and the credit card field would provide the application with a history of processed payments and facilitate other interactions such as reporting or processing refunds.

Then create a check out page with the purpose of collecting credit card and other information. Typically this page will contain a blank credit card field where they can enter their billing information. When they hit save on the page the credit card field will submit the payment information directly to Braintree for processing. At no point will any sensitive payment information be sent to the WorkXpress Application. If the payment is processed successfully then the page will save normally otherwise the user will see an error and the page will not complete the saving processes.

Fig. 2: The checkout page has a summary of the payment total and an area to enter payment information.

After the payment page saves the end user can either be directed to a page in the application or if the payment flow was being conducted in a popup then the window can be closed.

It is possible to pre-populate credit card information by reading the stored value of a previously saved credit card field from some other record. When this method is used the credit card field will render as non-editable because the actual payment information is stored in Braintree, not WorkXpress, so it can't be fully displayed or edited.

To achieve an interface for pre-population of payment information where the end user can edit the payment information, additional forms, fields, and actions will be needed.

• Start by adding a Container form that will hold the Field Grid form that has the credit card field on it.
• Under the When Form Loads (Display Trigger) for the container form add a Set Field Value action that pulls the stored value of a different credit card field and saves it on the current record in the credit card field being displayed.
• If the credit card field being copied from was used to process a transaction in the past, use an additional set field value action to clear the transaction id part from the credit card field to be displayed.
• Next create a Link field that has link text that reads something like “Click here to change the payment information” or “Click here to use another credit card”.
• Under the When Link Is Clicked trigger add a set field value action to clear the credit card field that is being displayed and a Reload Form action. This will cause the pre-populated data to be cleared and the payment information to reload and be displayed as editable.
• Create an Evaluated field that checks to see if the source of the credit card information does contain a value. If the source credit card field has a value then display the link because the credit card field will be populated, else display nothing because the field will already be displayed as editable.
• Finally place the Evaluated Field under the credit card field.

Extra Option: If you want to allow the user to revert back to the non-editable pre-populated value you can add an additional link that copies the value back into the credit card field and reloads the form. You can then display that link using the evaluated field when the source credit card field has a value and the current credit card field is empty.