Manual Identification URL

Merchants can redirect or link the users to this endpoint in order to “restore access” for a user to a specific item in case when a merchant is unable to confirm that the user has access to an item. This can happen when:

  • Merchant currently has no lptoken for a user or has one that has expired or one that points to a different user who has no access to an item.
  • A LaterPay user might have access to an item but the merchant is unable to confirm it using a MUID that they currently use for that user. This could happen if a merchant offered a purchase to a user using a different MUID before or simply without specifying a MUID.

In the above situations merchants can present a URL to this endpoint as a link labeled “I already purchased this” for example.

When a user visits this URL, LaterPay will identify them and check if they have access to the articles specified by the merchant in the URL’s configuration.

  • If the user has access, then LaterPay will redirect them to the back URL specified by the merchant.
  • If they don’t have access, they will see a dialog allowing them to sign in to their LaterPay account and if they do sign in, then LaterPay will again check the access. Users can also cancel this dialog at any time which will result in redirection to the back URL.

If the merchant doesn’t specify a MUID in the URL’s configuration, then when the user is redirected back to the merchant’s page, LaterPay will append an lptoken param to the back URL and the merchant will be able to receive it this way. See Receiving User Tokens for more details.

If the merchant specifies a MUID, then this MUID will be associated with the user’s LaterPay identity upon them visiting the manual identification URL.

This endpoint can be used as an extended alternative to /gettoken if a merchant uses lptokens to identify LaterPay users.


Base URLs:

Ident URL: /ident/<merchant_id>/<config_jwt>/

Merchant configures the URL for this endpoint, specifying:

  • <merchant_id> is the merchant’s ID.

  • <config_jwt> is a JSON Web Token (JWT) signed with merchant’s secret key using JWT’s HS256 signing algorithm, containing these fields:

    • A required ids array, containing of article IDs to check access for when the user visits the URL.
    • A required back string containing a URL to redirect the user to after they finish their interaction with the dialog.
    • An optional muid string containing a MUID. If this field is included, then LaterPay will not append an lptoken param to the back URL when redirecting the user back.


JWT allows LaterPay to securely verify that the configuration that is being communicated to us via the user’s browser is indeed the one created by you (the merchant). This security depends on your API Key being kept secret. Only you and LaterPay know this secret key.

Because of this, the tokens must be created (and signed with they key) server side and the secret key should never be disclosed to the public nor encoded in the JWT which is also public.

If possible, use one of the JWT libraries listed on and avoid creating your own implementation of JWT.

Your secret API Key can be retrieved from the “Developer” section in Merchant Backend. The URL that you use to access Merchant Backend depends on the region and environment of your integration. You can find the appropriate URL in section URLs of Merchant Backend.


An exp (Expiration Time) JWT claim can be included in the token payload and it will be validated by LaterPay and URLs with expired tokens will return a Not Found page to the user.

Impact of any caching mechanisms used by the website should be considered before including the exp claim.

If there is no exp claim set, the token will be valid virtually forever i.e. as long as the merchant account is active.


Assuming the JWT’s payload is

    "back": "",
    "ids": ["article_id_premiumcontent_123", "article_id_timepass_4"]

And Merchant’s ID is pnNa4VUu35vomSdTztA6Lj and merchant’s secret key is e50837aa2d424abe4f7d32d89fe8a0ba. Then a valid Manual Identification URL can look like this:

And this is a different living example showing how the dialog looks.