> ## Documentation Index
> Fetch the complete documentation index at: https://waffo.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Portal Sign-in, Links & Account Status

> Why the Merchant Portal signs you out, how long every email link stays valid, why a resend is refused, what the password expiry and reuse rules are, what Continue with Google does, and which account statuses can and cannot sign in.

This page is about getting **into** the Merchant Portal: sessions, email links, passwords and
account status. Role permissions, inviting teammates, login history and two-step verification are
covered in [Merchant Portal Operations](/docs/en/support/portal-operations-faq). The first-time
sign-up, sandbox and account-verification path is covered in
[Self-Serve Sign-up, Sandbox & Account Verification](/docs/en/support/getting-started-self-serve-faq).
API credentials and public keys live in
[Portal Self-Service Security Configuration](/docs/en/support/portal-security-config-faq).

Every message quoted below is the exact text the Portal shows, so you can match what you see on
screen to the cause.

## Why does the Portal keep signing me out?

The Portal session is **idle-based, with an absolute ceiling**:

| Rule | Value | What it means for you |
| - | - | - |
| Idle timeout | 8 hours | A session with no activity expires. Activity renews it. |
| Renewal threshold | 4 hours | The session is only extended once less than 4 hours of its window remains — so a short burst of activity does not reset the clock every click. |
| Absolute maximum | 16 hours | Even a continuously active session ends here. You must sign in again. |

When the session is gone, requests come back as `Session expired.` and the Portal returns you to
the sign-in screen. There is no way to lengthen these windows from the Portal.

Two other things end a session immediately, before any timer:

* your account being locked after repeated wrong passwords (see below);
* your role being changed by an administrator — see
  [Merchant Portal Operations](/docs/en/support/portal-operations-faq).

## How long is each email link valid?

Four different emails carry four different links, and their lifetimes are **not** the same. This is
the single most common source of "the link says it expired" tickets.

| Email | Link lifetime | Reusable? |
| - | - | - |
| Team invitation (an admin added you) | **24 hours** | No — single use |
| Password reset ("Forgot password") | **30 minutes** | No — single use |
| Self-serve sign-up activation link ("Magic Link") | **15 minutes** | No — single use |
| Sign-up one-time code (OTP), where you chose the code instead of the link | Short-lived; the Portal shows the countdown | No |

An expired or already-used link does not silently fail — you get a specific message:

| What you see | Cause |
| - | - |
| `Verify email is expired.` | The invitation or reset link is past its lifetime |
| `Invalid email verify token.` | The link was altered, already consumed, or does not match this account |
| `Sign-up link is invalid or expired.` | The 15-minute self-serve activation link is no longer usable |

In every case the fix is the same: request a new one. Nothing is lost — the link only proves it is
you, it does not carry your data.

## I asked for a new link and nothing arrived. Why?

Because there is a short per-minute cap on these emails, and hitting it returns a message rather
than a mail:

> `Reached the message send times limit, please try again later.`

The cap is counted separately for password resets and for invitation / sign-up-activation emails.
Resending the activation link uses the same budget as invitations.

So if you clicked *Resend* several times in a row, the later clicks were refused and the earlier
mails are the ones in flight. Wait a minute, then request once and check:

1. the spam / junk folder;
2. that the address is the one your administrator actually invited;
3. that your mail server is not quarantining external senders.

If none of that explains it, ask your administrator to re-send from the team member list, which
also shows whether the account is still `Pending`.

## What are the password rules beyond complexity?

[Merchant Portal Operations](/docs/en/support/portal-operations-faq) covers the complexity requirement.
Three further rules decide whether a password change is accepted at all:

| Rule | Behaviour |
| - | - |
| Format | At least 8 non-blank characters, with at least one uppercase letter, one lowercase letter and one number |
| Reuse | A new password **cannot match any of your last three passwords** |
| Expiry | The password expires **90 days** after it is set |

The messages map one-to-one:

| What you see | Meaning |
| - | - |
| `The password format must be at least 8 non-blank characters, at least one uppercase letter, at least one lowercase letter, and at least one number.` | Complexity not met |
| `For security reasons, your new password cannot be the same as your last three passwords` | Reuse rule hit — pick a genuinely new one |
| `Passwords do not match.` | The two fields differ |
| `Wrong password.` | The *current* password you typed to authorise the change is wrong |

The reuse check runs both when you change your password while signed in and when you set one
through a reset link, so cycling back to an old password is not possible in either path.

## The Portal forced me onto a "set a new password" screen. What happened?

Your password reached its 90-day expiry. Sign-in succeeds but returns:

> `Your password has expired. Please set a new password for enhanced security.`

and the Portal routes you to a forced password-change screen. This is not skippable — no other
Portal page will load until the new password is set. The new password must satisfy the format rule
and must not repeat your last three, so have a fresh one ready. Setting it also restarts the
90-day clock.

Password-based sign-in is what triggers this. If you signed in through Google, the expiry check
does not stand between you and the Portal — but your password stays expired for password sign-in
until you change it.

## My account is locked. How long, and what unlocks it?

Wrong-password attempts are counted for **one hour**. The **fifth** failure inside that window
locks the account:

| Step | What happens |
| - | - |
| Failures 1–4 | Sign-in refused with `Username or password wrong.` |
| Failure 5 | Account status becomes `Locked`; the unlock time is set **1 hour later**; any active session of yours is revoked |
| While locked | Sign-in refused with `Your account is temporarily locked. Please try again later.` |
| After 1 hour | The account returns to normal by itself |

Two consequences worth knowing:

* The counter only runs on accounts that are currently `Active`, so failures against an account
  that is already `Pending` or `Locked` do not stack further penalties.
* A successful sign-in clears the counter, so four failures followed by a success leaves you with a
  clean slate rather than one attempt remaining.

There is no Portal button to unlock early. If you cannot wait, an administrator on your account can
help you through the reset-password path — the reset link is independent of the lock timer.

## Which account statuses exist, and which can sign in?

Only one status can sign in. The rest each produce their own message:

| Status | Can sign in | What the Portal says / does |
| - | - | - |
| `Pending` | No | `The user needs to set the password first.` — the invitation was never completed. Use the invitation link, or ask for a new one |
| `Active` | **Yes** | Normal sign-in |
| `Locked` | No | `Your account is temporarily locked. Please try again later.` — temporary, see above |
| Any other status | No | `User disabled.` |

In **Settings → Members**, your team list labels the first two — `Pending` and `Active` — because
those are the two states an invitation flow produces. A row showing anything else is an account
that can no longer sign in, and only an administrator can act on it.

`User disabled.` is therefore not a bug report: it means the account exists but is no longer in a
state that permits sign-in. Contact an administrator on your merchant account rather than
retrying.

## What does "Continue with Google" do?

It sits on both the sign-in and the sign-up screen. Clicking it opens Google's own consent window;
Waffo never sees your Google password.

What happens next depends on what already exists:

| Situation | Result |
| - | - |
| Your Portal user already exists with that email address | You are signed in, and the Google account is linked for future sign-ins |
| Your Portal user exists but is still `Pending` (invited, never activated) | Google's proof that you own the address activates the account, then signs you in |
| No Portal user exists for that address | An account can be created this way only where self-serve sign-up is open — see [Self-Serve Sign-up](/docs/en/support/getting-started-self-serve-faq). Where it is not, sign-in is refused |

Two rules always apply:

* Google must report the address as **verified**. An unverified Google address is rejected.
* The status check above still runs. Google sign-in does **not** bypass a locked or non-active
  account.

Because the link is made on the email address, signing in with Google and signing in with a
password land you on the *same* Portal user — not a second account. If Google sign-in fails
unexpectedly, the Portal surfaces the reason inline; retry once, then fall back to email and
password.

## Why does the sign-up form make me pass a "security check"?

Self-serve sign-up sends a real email to the address you type, so the first send is protected by a
human-verification challenge. If it does not pass you get:

> `Security check failed. Please refresh and try again.`

Refresh the page and submit once — a stale page is by far the most common cause, because the
challenge is only good for a short time. The check runs on the send that starts sign-up, not on
every subsequent step.

## What is the invitation code field on the sign-up form?

It is **optional**. Leave it empty and sign-up proceeds normally.

If you *were* given a code and it is not accepted, the message is:

> `The invitation code is invalid.`

Codes are exact — no leading or trailing spaces, correct case. If it still fails, ask whoever gave
it to you rather than guessing, and note that removing the code lets you register anyway.

## I tried to sign up but the address already has an account.

You get `Email already exists.` and no second account is created. One email address maps to one
Portal user, so:

* if you set a password before, sign in with it;
* if you never finished the invitation, use the invitation link, or ask your administrator to
  resend it;
* if you do not know the password, use **Forgot password** — that works on an existing account
  regardless of how it was created.

Repeating sign-up will not produce a fresh account, and it consumes your per-minute email budget.

## Can I choose the link or a code when signing up?

Yes. Self-serve sign-up supports two ways of proving you own the address:

| Method | How it works | Validity |
| - | - | - |
| Activation link (default) | You receive an email with a one-time link; opening it activates the account | 15 minutes |
| One-time code (OTP) | You receive a numeric code and type it into the form | Short-lived; the form shows the countdown |

Both prove the same thing, so pick whichever your mail setup handles better — the link path is
easier when mail arrives on the same device, the code path when it does not. Either way the
account is created once, and the per-minute send cap applies to both.

## Sign-in worked, but the Portal says my user is not attached to a merchant.

The message is:

> `User not set relation merchants. Please contact your administrator to set the relation merchants.`

Your credentials are fine; the account simply is not associated with a merchant account yet, so
there is no data for it to open. Only an administrator can attach it. This most often appears
right after an account is created outside the normal invitation flow.

## Does the Portal ask for a verification code at every sign-in?

Only if two-step verification is switched on for your user. That, including the case where it
appears without you enabling it and what to do when the code does not arrive, is covered in
[Merchant Portal Operations](/docs/en/support/portal-operations-faq) and
[Portal Self-Service Security Configuration](/docs/en/support/portal-security-config-faq).

For sizing expectations here: the code is delivered by email, is short-lived, and resending it is
rate-limited in the same spirit as the link emails above — repeated clicks return
`OTP rate limit exceeded.` rather than more messages.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.