The last step in the enrollment flow is the payment step. Both postpaid customers (deposits) and prepaid customers (credit) should be prompted to initiate a payment if required.

The payment system integrates with our payment processor (Elavon) via encrypted HTTPS to tokenize customer payment information. When a customer provides card or bank details, these are securely transmitted to Elavon, which returns a token. This token is stored as a payment account on the Customer’s account for future transactions and can also be used to setup automatic recurring payments.

Before processing any payment, the system checks the token against existing stored tokens. If a matching token is found on an account restricted to cash-only payments, the transaction is rejected with an error response. For valid tokens, the system processes either the required deposit (postpaid customers) or account prepayment (prepaid customers).

This completes the final step in the customer’s enrollment journey.

iFrame Payment Widget Documentation Copied

The iframe payment solution is a way to include the ability for your customers to make a payment during enrollment directly within your website without forcing them to visit a separate site to process the credit card transaction, all while protecting you from PCI Compliance liability and risk. The solution involves a customized url specific to your organization along with a customized payment form and confirmation message that is consistent with your brand and visual identity.

The solution consists of the following steps:

1. Your customer visits your website and begins the enrollment process

2. Once the enrollment is complete and an account number is issued the page containing the confirmation number will need to include an iframe pulling in the payment page hosted at paylesspower.com with parameters passed via the url string (i.e. Account number and ESIID).

3. The contents of the iframe checks our API to verify an ESIID/Account Number match and then retrieves the relevant data to pre-populate the form (minimum payment, service address, etc.)

4. Once the credit card transaction is complete, the user is redirected to the confirmation page and the credit card transaction confirmation number is passed in the URL

In addition to the Account number, ESIID and confirmation url, we are also supporting the ability to pass a language selection (Spanish with a default to English)

Here’s a few examples (using the sandbox environment):

• Only required parameters (Account Number and ESIID):

• https://account.paylesspower.atmo-dev.com/makepayment?id=1001107&esiid=10032789437767611

• Custom language:

https://account.paylesspower.atmo-dev.com/makepayment?id=1001107&esiid=10032789437767611&language=es

 

The make a payment page needs 2 required parameters:

• id — The account number to retrieve.

• esiid — The associated ESIID for validation.

It uses these two fields for verification and to retrieve the account details.

If either of these two is missing, or if they don’t match (wrong ESI ID for the account number), the page will display a generic API error message.

In addition to the 2 required parameters, there are other optional parameters:

• redirect — A fully-qualified URL to redirect to after successful payment. 

  • If none provided, or if the provided value is not a valid URL, the page will show the normal enrollment confirmation screen.

  • When redirecting, the app will append a confirmation variable to the provided URL with the payment confirmation number (i.e. redirect=https://paylesspower.com would end up at https://paylesspower.com?confirmation=XXXXXX)

• language — A locale string to force a specific language preference. Accepts “en” or “es”. 

  • If none provided, or if the provided value is invalid, the page will use the normal enrollment language inference logic.

• affiliate — six digit agent ID, will set the customer care phone number accordingly.

• paymentAmount — default payent amount.