Event UX

[andymckay-limited-access]

In the documentation we list some potential events that get sent to users, as information and security features. Those are:

http://payments.readthedocs.org/en/latest/design/api.html#events

Let's check those make sense and get a plan for how they'll look. Just all emails in the style of Firefox Accounts?

[brampitoyo]

Here are my recommendations on handling various events via email notification.

Payment method created.

When a new credit card is added event, it’s immediately visible on the purchase flow.

There’s no need to send an email unless we’re concerned about unauthorised access. (For example, Facebook would tell you if you’re signed in from an unknown device.)

Payment method updated for subscription.

Gist: each subscription can be paid with different credit cards. When the credit card change, should we send an email that says “This subscription is now paid using B instead of A”?

• If card is updated then immediately used to pay, email receipt will contain the new card information in it. No need for separate notification.
• If card is updated but not used to pay until sometime afterwards, should we let user know? Probably not.
  • First of all, card is always updated manually, so user always know that it has happened
  • Secondly, when the email receipt comes a few days/weeks later, it will contain the new card information in it

Subscription created.

This notification is be bundled with the email receipt. A subscription receipt will have an extra field that says “Next payment”.

This makes a separate “You’re subscribed to [product]” email unnecessary.

Subscription charge succeeded (e.g. every month).

Email receipt will indicate that the charge has succeeded.

Subscription charge failed.

This will need email notification. It should at the very least specify:

• Subscription name/logo
• Amount
• Payment method used
• Link to fix it

On the link to fix it, user can do these things:

• Try again with the same method
• Edit method, then try again
  • Change it with another method that’s already stored
  • Add a new method, then use it

I’m not sure where this link should lead to. Should it lead to the buy flow iframe, or the payments dashboard instead? I am tempted to keep things really simple and just rely on the buy flow for everything.

Subscription cancelled.

More important than the notification itself is acknowledging two things:

• Reassure user that the payment method is not going to be charged again
• Reiterate whether the subscription is still valid or not
  • If still valid, then until when? Give exact date
  • If not valid, then we should let it know that subscription will cease the moment user clicks “cancel”

I think this is a job that can be accomplished using a really good cancel UI. It should say “Your subscription will be valid until [date]/Your subscription will instantly terminate. [Keep my subscription/Cancel]”

Summary: should we send email notification during this event?

• Payment method created: no
• Payment method updated for subscription: no
• Subscription created: no
• Subscription charge succeeded (e.g. every month): no
• Subscription charge failed: yes
• Subscription cancelled: no

[andymckay]

That's awesome and makes sense to me. The only reason I can see a need for some of these notifications is the possible security component and the worry of unauthorized access. The notification provides an out of band message that makes it one bit harder to fake.

For "Subscription charge succeeded", you say "Email receipt will indicate that the charge has succeeded." So that sounds like we are sending an email in this case, it's just the email receipt?

Any chance you could pretty much copy and paste that into the docs and send in a pull request?

https://github.com/mozilla/payments/blob/master/docs/design/api.rst#events

[brampitoyo]

Yeah. Security and access were my concerns, too, so we’re on the same page!

For "Subscription charge succeeded" […] that sounds like we are sending an email in this case, it's just the email receipt?

Yes. We’re just sending the receipt itself. We won’t send a separate email that says “The charge came through”.