MUIDs - Merchant Provided User IDs¶
As an alternative to lptokens, merchants can provide their own identifiers for each user of their service. We call them MUIDs - Merchant User IDs.
MUIDs allow merchants to integrate LaterPay to their existing user identification mechanisms. Merchants using MUIDs need to be able to generate and assign MUIDs to their users’ accounts/sessions and track them for their users.
Merchants can initiate the process of binding their MUID to a LaterPay user in several ways:
Access API’s /access endpoint supports a
query parameter and merchants can use it to ask for access status information
for their users identified by MUIDs.
A valid MUID is a string of a length between 1 and 80 characters. Allowed characters are:
- Upper and lowercase ASCII letters
MUID to LaterPay user associations¶
One MUID can point to only one LaterPay user identity at a time. This means that following scenario is true:
- Merchant shares a MUID carrying URL with user X.
- User X visits the URL from (1). Now the MUID points to User X’s LaterPay identity. This means that if the merchant uses this MUID to query for /access data, then the results will refer to user X’s access status for given items.
- Merchant shares the same MUID with user Y.
- After user Y has visited the URL from (3), the MUID points to User Y’s LaterPay identity and no longer to user X’s.
If multiple different MUIDs are shared by one merchant with one LaterPay user using different URLs, then after the user visits all of these URLs, these MUIDs will point to the same LaterPay user’s identity.
Our recommendation is for merchants to try to keep the above relationship a one to one. Meaning, the merchants:
- Should avoid presenting the same MUID to different users (as far as they can recognize that these are different users).
- Should try to always use the same MUID for the same user (user being someone identified by the merchant and visiting the merchant’s site).