Payment Vouchers
- Seth Petry-Johnson
- Edwing Arana
- Christopher Butcher
- Jacob Brown
Summary
Payment Vouchers allow one entity, usually an employer or organization, to pay the credentialing fees incurred by another entity, usually a practitioner. Vouchers improve the user experience for all parties involved by avoiding the need for after-the-fact expense reporting and reimbursement.
Primary Business Case
An employer or organization wants to cover the fees / costs of getting their workforce certified and wants to avoid individual reimbursements to individuals.
For the purposes of clarity this documentation refers to the employer/employee model, but Vouchers could be used in any scenario in which one entity is arranging payment on behalf of another entity and where we can establish a "Responsible Party" relationship between them.
User Stories
The following user stories apply to Vouchers:
- As a Program, I define methods for Organizations to satisfy Application fees through one or more Voucher Code;
- As an Organization, I purchase a fixed number of Vouchers that my employees will use to satisfy Application fees;
- As an Organization, I assign an Voucher to an individual;
- As an Individual, when I reach the Checkout step for a transaction, I enter the Voucher Code to defray the payment amount corresponding to the value of the Voucher;
- As an Organization, I see which Vouchers I purchased have been redeemed;
- As an Organization, if an Employee leaves my Organization, I can reissue a Voucher Code that has not been redeemed so that the original Voucher Code cannot be redeemed;
Financial Models
Currently Supported? | |
|---|---|
| Organizations pre-pay in advance using a credit card |
(9.3) |
| Organizations pre-pay in advance using a Purchase Order |
(9.3) |
| "Bill me later" model where applicants use a specific code to satisfy the Payment, and the organization is billed at a later date for only the number that get used |  |
Voucher Models
Currently Supported? | |
|---|---|
Organizations can purchase codes that provide a discount up to a fixed dollar amount. Anyone that knows the code may use it, and applying the code to an application payment will reduce the balance due by the appropriate amount. |
(9.3) |
Product Vouchers By connecting Vouchers to specific Products, usage can be restricted beyond what is possible with Discount Vouchers. For example, a Voucher could be created that can satisfy a number of different application fees but will never apply to a late fee. |
(fully designed, not implemented) |
Manual assignment to existing LearningBuilder members Organizations with a small number of employees who already exist in the system can pre-pay for a batch of certifications by purchasing vouchers, and then manually assign them to specific employees. Those employees would then go through the normal Workflow, automatically bypassing the payment task by virtue of the assigned voucher. |
(fully designed, not implemented) |
Manual assignment to employees NOT already in LearningBuilder Organizations with a small number of employees who may NOT already exist in the system can pre-pay for certifications by purchasing vouchers, which are then delivered to the recipient in an email containing a personalized message. Following a link in the email allows individual to register in LearningBuilder and automatically establishes the payment voucher to the account. |
(fully designed, not implemented) |
Bulk assignment by cohort Organizations with large number of employees may find the task of individually assigning vouchers to specific employees onerous. These organizations may want to simplify the process by searching for employees based on aggregate details (i.e. everyone in a specific department, or everyone with a current certification expiring within 6 months) and then applying vouchers to the entire cohort as a single action. |
(concept stage) |
Promotional voucher codes The Discount Voucher Codes feature generates a unique, random code for each Voucher that is purchased and requires that the purchasing organization assign each code to a specific purpose. An alternative use case involves the purchase of a single, static code (such as "GET-LICENSED-2019") that can be advertised to a wide audience, such as during a promotional event at a conference. ("The first 10 people that submit their application payment using this code get 50% off their application fee!") This could be implemented either as a fixed up-front purchase or in the "bill me later" model. |
(concept stage) |
Known Limitations
- The amount paid within a LearningBuilder session for a given user's payment is dependent on the most recently edited Checkout Cart*. For example, if a user has a Checkout Cart open in both Tab A and Tab B and applies the voucher to Tab A, then that voucher is also applied in Tab B. The user may not see the voucher applied in Tab B through the UI unless they refresh their page first. *This limitation does not apply to a PayflowPro/HostedPagesIFrame configuration. With PayflowPro/HostedPagesIFrame, payment is taken based on what is listed in the UI through which the payment is being made, regardless of whether there exists a more recently edited Checkout Cart in a separate tab.
- There is an inconsistency between how we handle vouchers dependent on the Payment Gateway and the VoucherEnabled app configuration setting. For Moolah and USAePay, there is no option in the UI to apply a discount or voucher code regardless of whether VoucherEnabled is set to True. For Alabama Interactive, if VoucherEnabled is set to True, then the ability to apply a discount or voucher code is enabled in the UI. However, our current posture for all three payment gateways remains the same. That is, we do not support the use of vouchers for any of these gateways.
- When an Admin attempts to purchase a voucher for an amount different from the purchase price, a validation error will appear. While we allow manual entry to the payment price, at this time, we are not allowing values that differ from the total.