Coupon flow for user without an account

[pdpinch]

As a sales person, I'd like to be able to send a 100% off coupon (or enrollment code) to a learner without an account and have them easily create an account, enroll in the appropriate course and view the courseware.

Designs and Mockups

There are a couple of use cases:

1. A company sends a list of e-mail addresses for us to enroll in a certain course.
2. We (sales) sends coupon codes to a company for them to distribute to their learners

Technically, in both use cases we end up (or should) with learner clicking on a link that looks like
xpro.mit.edu/enroll?code=yyy

If learner is logged in when they click the URL with the coupon code, then we should apply the coupon normally in the checkout page.

If learner is not logged in, they need to login or register first. When register, they’d have to verify the e-mail etc. so we’d have forgotten about enrollment code at that point. A desired workflow in that case would be:

1. Redirect learner to /login?code=yyy
2. Learner provides e-mail address and clicks ‘next’. At this point we store the e-mail + coupon_code.
3. The same should happen if learner goes to /signup?code=yyy

At this point, when learner comes to our website from anywhere, we can check if there are are any unredeemed coupons associated with their e-mail address

Acceptance Criteria:

• Enroll endpoint that that takes a coupon parameter and redirects a logged in user to the checkout page; if the user is not logged in redirects to the /login endpoint with a next parameter
• PendingEnrollments table to keep track of email address and coupons they intend to use
• for unregistered users, add their email and coupon code to the PendingEnrollments table

Questions

• Q: do we create an account for user before email is sent?
  A: No. Accounts are created as normal, when the user validates their email and completes their profile.
• Q: is email validation required?
  A: Yes.

[pdpinch]

I updated the description after discussing with Ferdi. I don't think this requires an RFC any more.

[rhysyngsun]

@pdpinch When redirecting to the /login or /signup we should instead specify the next as /enroll?code=X url since that's already supported out of the box and we shouldn't complicate login/register by requiring it to support coupon logic.

[rhysyngsun]

So, there's one deficiency with using the next parameter that will probably make that approach a nonstarter:

• This is bound to their session so there are cases where it gets cleared and they lose the association (e.g. clicking on the confirmation link on a different device)

I think we should keep two goals in mind in the approach/choices we decide on:

• Keep auth code as simple as possible
• Minimize edge case surface area for the end user

There are a few options for how to handle this with some tradeoffs:

• Persist the redirect_uri in a db model and hydrate this into the session as the last step of the pipeline
  • Pros:
    • Implementation is simple and would be a drop-in to the current pipeline
    • User has the opportunity to see a checkout page
  • Cons:
    • Does not support multiple codes being redeemed at a time (if the user clicked on multiple codes for a given email, we'd need to decide which behavior we want, e.g. first click wins, last click wins, etc)
• Resolve any coupon redemption links the user has clicked on for a given email when registration/login is complete
  • Pros:
    • Implementation is simple and would be a drop-in to the current pipeline
    • Supports multiple codes being redeemed
  • Cons:
    • Does not support the user viewing a checkout page
• Somehow incorporate the checkout page into the login/registration pipeline (devil's advocate option)
  • Pros:
    • Supports multiple codes being redeemed
    • Supports auser seeing a checkout page for each coupon code
  • Cons:
    • Complicates and tightly couples both auth and checkout code by requiring them to integrate with each other
    • As with any other tight coupling, I would expect some unforeseen edge cases to arise out of this approach

[rhysyngsun]

@pdpinch still need to decide from a product perspective which of the options above we want before I can begin implementing. I am only strongly opposed to the last one.

[pdpinch]

No. 1 is the best choice. We need the user to see the checkout page to fit in with coupon and data consent flows.

[pdpinch]

I think this is working now, but it would be worth testing it all the way through at least one more time.

[pdpinch]

Looks like this has been working for some time.