• MultiAccountAdminAndPayments

Working on SignupAndUpgradeFlow provides some reminders of additional features that users sometimes ask us about. One that comes up on a semi-regular basis (and is probably desired often but asked for less often) is how to pay for multiple JMP numbers as once and/or "administer" multiple JMP numbers. We want to at least provide a way for people to pay for multiple JMP numbers at once, since it's good for them (less time spent paying, as there are fewer payments to make), and good for us (a few larger transactions is less support work and transaction fees than a lot of small transactions). Here is a general design for that, focusing on the database model, and using that as a lens through which we see its effects on usability:

Basic payment schema

Notes written in April 2018 on the schema to use, which is not yet fully realized, but provides a good framework for the additions we want to make for the multi-account support:

rough set of keys to use

• "payment-plan_as_of_YYYYMM-JID" - key of plan that is in effect for given month
• "payment-balance_prepaid-JID" - in this month's plan currency (careful not to convert)
• "payment-amount_paid_YYYYMM-JID" - currency matches plan_as_of_YYYYMM-JID currency
• "payment-user_type-JID" - "type" of user so know what plans to show
• "payment-funding_method-JID" - how the account is funded (recurring? prepaid?)

Extensions for multi-account payments

To make the above work with multi-account payments, we'll need a few more keys:

• "payment-leaf_jids-[index]" - a list of JIDs that are paid for by the same "account"; the first JID in this list is the one that pays for the others
• "payment-leaf_jids-total" - the current number of "payment-leaf_jids-[index]" keys - so we can easily iterate over all of them (see below)
• "payment-leaf_jids_index-JID" - the index of the Redis list containing the JIDs that are paid for by "JID"'s "payment-balance_prepaid-JID"

(We might call "leaf_jid" something like "extra_jid" instead.)

If a person wants to pay for an additional JID, they'll do so via the account bot. There are two options

1. They add an existing trial user to their account.
2. They create a referral code that lets other accounts signup using this main account as the payer (see SignupAndUpgradeFlow for code details).

In both cases, the end result of the extra account being added (after the account signs up in the second case) is that we create the "payment-leaf_jids-[index]" list if it's not there again, and ensure it has at least two elements: the JID of the first ("main") account and then the additional accounts that will be paid for by the first JID's "payment-balance_prepaid-JID".

Note that the "payment-balance_prepaid-JID" key won't exist for trial users - they will also have "payment-plan_as_of_YYYYMM-JID" that is of a trial type. A leaf account won't have a "payment-balance_prepaid-JID" key of its own either, but they will have a "payment-plan_as_of_YYYYMM-JID" that is of a non-trial type - that is how one can differentiate the two.

User interface

For main account

The main account can see all the JIDs and JMP numbers that it pays for (with an account bot command). This is easily done by looking up "payment-leaf_jids_index-JID" then "payment-leaf_jids-[index]" and doing extra lookups to get each JMP number from the JIDs.

It may be that we want the main account to be able to see usage info for the leaf accounts too.

For leaf accounts

The leaf accounts don't actually "know" which main account they're attached to. So we need to iterate through all "payment-leaf_jids-[index]" lists to find which one they're in (we'd do this at addition time to prevent dupes), and then we'd give them either the JID or JMP number of the main account - this should be fine for a while as we won't have to do this often (only when a user wants to see who their "main" account is) and there shouldn't be many of them.

The user can then use that info to contact the "main" account if they need to discuss things with that person (an administrator of sorts you could say).

Privacy considerations

The "current" system for payments used by JMP (without any of the above "payment-*" keys) does reveal which whether a JID or phone number is used by a JMP user (but it does NOT allow a random person to see which number has which JID or vice versa). This is a side-effect of how we do payments currently, where the Redis database doesn't actually know who has paid and who hasn't, so instead we check if the number/JID belongs to a JMP user at all, as a way of doing basic verification.

We'd prefer that arbitrary people not be able to know whether a JID or phone number belongs to a JMP user. The above design mostly allows for that, except in the case of trial users, where it is still possible to check if a JID has a trial account, since we'd need that for the #1 step in the Extensions section above. It may be possible for us to hide even that, but might not be worth it. Also, it may incentivize people to pay for a JMP account (not as a primary goal of this, of course - just an unintended consequence).