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

# Accept or Decline Service Invitation Process

## Multiple Process Orchestration

Also known as the "Accept or Decline Process" for short, this Process allows an end user, who has been invited by another user to share an account or service, to explicitly accept or decline the invitation.

Most user journeys are facilitated by a single Process. Conversely, there are some cases where Storefront Gateway orchestrates and links two or more Processes to complete a given journey.

<img src="https://mintcdn.com/amdocs-spbu/0TZ9XF1Mst_2ATcV/marketONE/sgProcessGuide/images/m1c_multipleProcessAcceptOrDecline.png?fit=max&auto=format&n=0TZ9XF1Mst_2ATcV&q=85&s=a609fe41d7afd57d53d2a6521f582db0" alt="" width="1431" height="295" data-path="marketONE/sgProcessGuide/images/m1c_multipleProcessAcceptOrDecline.png" />

The **Accept or Decline** Process completes a two-Process, two-user journey initiated by a preceding [Accept or Decline Service Invitation Process](c_acceptDeclineServiceInvitation) Process.

## New User Creation

In the event that the invitee does not yet have their own Storefront Gateway User ID, then this Process automatically handles and completes the new user onboarding for the invitee. Once the invitee accepts, the Process will prompt your client for a password, and your client will need to pass that prompt to the front end.

## Process Invocation

Unlike most Processes, The Accept or Decline Process is **not** invoked with the Process Start API. Instead, your client leverages the [Session Token](c_sessionToken) API to redeem a [Storefront Gateway Action Token](c_actionTokens) that was generated by a previous Process (the [Share Access to an Account, Subscription, or Feature](c_shareAccessASF) Process.

There are two methods to call the Session Token API in order to start a Process. Each method is appropriate to the type of notification that the user receives, either a clickable verification link, or a short One-time Passcode (OTP) that the user needs to give to the UI:

**Method one: redirect URL with token value**

```
GET https://{your.url}/session/token?token={**token value**}
```

1. The user completes a Process.
2. Storefront Gateway issues an action token, and sends a verification link in an email or SMS. The link is composed of a redirect URL back to your client application, and the full, actual token string is appended to the end of that URL.
3. Once the user clicks/taps the link, they are redirected back to the client.
4. The client automatically takes the token value directly from the URL, and uses it to call `GET /session/token?token={**token**}` API. If the token is valid, then this triggers the Activate User Process.

**Note:** If your organization is sending clickable link notifications, then you'll need to do a few things to facilitate the flow:

* You'll need to create the actual landing page that will invoke this API method when opened.
* You'll need to set the redirect URL to that landing page in the Storefront Gateway Admin console, on the Security settings page. This allows Storefront Gateway automatically send the appropriate link to the user once they've completed the first half of their journey. See the Security Settings section in the Admin Guide for more details.

**Method 2: One-time Passcode (OTP) token**

```
GET https://{your.url}/session/token?customToken={**OTP**}&pkat={**PKAT**}
```

1. The user completes a Process.
2. Storefront Gateway sends a short, custom One-time Passcode (OTP) in an email or SMS. Storefront Gateway also returns a PKAT to the client.
3. The client prompts the user to enter the OTP that was sent to them.
4. The user retrieves the code, and enters it into the client.
5. Once the user enters their code, the client then takes the OTP and the PKAT to call `GET /session/token?customToken={**otp**}&pkat{**pkat**}` API. If both the OTP and PKAT are valid, then this triggers the Activate User Process.

When your organization onboards with Storefront Gateway, you'll determine the type of notification messages you want Storefront Gateway to generate and send to end users, and what action token type they receive in those messages (i.e., a clickable link, a short code, or both). Once you have your settings in place, you'll then need to build your application to use the appropriate method for redeeming action tokens.

**Note:** The invitee can only invoke this particular Process using a clickable redirect URL that they receive in either an email or SMS. Your client won't have any knowledge of the PKAT that is needed to redeem an OTP when the invitee visits your application. So the first method above is the only applicable one for service invitees. Both methods are included here for context.

## Process Flow

This flow describes the Process at a high level.

**Preconditions**

* A separate user has sent the invitation using the [Share Access to an Account, Subscription, or Feature](c_shareAccessASF).

**Basic Flow**

1. The user clicks on the invitation link in their email or SMS.
2. The invitee's browser redirects to the client application.
3. The client invokes the Process, using the token taken from the redirect URL.
4. Storefront Gateway responds with a prompt for the user to accept or decline.
5. The user clicks **Accept**, and the client passes this back to Storefront Gateway.
   1. If the invitee is a **new** Storefront Gateway User, then the Process returns an additional prompt to the client for the user to complete their onboarding
   2. The client displays the user's verified contact channel (the email or mobile to which the invitation was sent) and prompts the user to provide a password.
   3. The invitee submits a valid password, and the client passes that back to Storefront Gateway.
6. Storefront Gateway fully activates the invitee's User ID and the email/mobile registered to it.
   * On the back end, Storefront Gateway updates the User entity status, and authN ID status, to `activated`.
7. Storefront Gateway fully activates the invitee's access to the shared account or service.
   * On the back end, Storefront Gateway updates the User-to-Account (or Subscription, or Feature) association status to `activated`.
   * Storefront Gateway updates the User-to-Group association status to `activated`.

**Post-conditions**

* The invitee is now a fully activated Storefront Gateway User, and they have access to the shared account or service represented by the Storefront Gateway Account, Subscription, or Feature.
* Storefront Gateway automatically authenticates the user.
* Storefront Gateway sends a confirmation message to the account/service Primary User.

**Possible or Common Errors**

* The provided password does not match validation rules.

| User Declines |
| - |
| If the invitee instead **Declines**:- Storefront Gateway removes the user from the user group (if they were not already a member). - On the back end, Storefront Gateway removes the User-to-A/S/F association and the User-to-Group associations. - Storefront Gateway removes the Storefront Gateway User entity, since the invitee did not accept and thus did not complete onboarding. If the invitee never opens the invitational email, then Storefront Gateway will, after a set amount of time, remove any User entities and/or associations with an `activating` or `pending` status. |

## Settings

Certain aspects of the Process' behavior are controlled by configurable system settings. Your organization can manage these and other settings in the Admin console.

| Application Settings | Default Setting | | |
| - | - | - | - |
| **Password Complexity Rules** | Defines the criteria for a valid password when the user is onboarding, or resetting/updating their password. Configuration points include:- **Upper case characters** - The password requires at least one uppercase (A-Z) character. - **Lower case characters**The password requires at least one lowercase (a-z) character. - **Special characters**The password requires at least one [special character](reusePasswordSettingSpecialCharsList). - The password requires at least one numeric (0-9) character. - The minimum password length. | - A-Z: Enabled - a-z: Enabled - (!"#\$%&'()\*+,-./:;=>?@\[\\]^\_\`\&#123;\\ | \&#125;\~): Enabled - 0-9: Enabled - Minimum length: 8 |
| **Long Token Expiration Period** | Determines the number of minutes before the invitation link expires. | 28800 (20 days) | |

## User Journey Diagram

This diagram illustrates the standard user journey using the **Accept or Decline** Process.

<img src="https://mintcdn.com/amdocs-spbu/0TZ9XF1Mst_2ATcV/marketONE/sgProcessGuide/images/sfgw_userJourneyAcceptOrDeclineInvite.png?fit=max&auto=format&n=0TZ9XF1Mst_2ATcV&q=85&s=d00e8cce65580059a15ad93f8176fb10" alt="" width="1750" height="2247" data-path="marketONE/sgProcessGuide/images/sfgw_userJourneyAcceptOrDeclineInvite.png" />

## Use Cases

The following use cases provide guided API walkthroughs of this Process for client developers:

* [New user accepts invitation](c_useCaseAcceptInviteNewUser)

* [Existing user accepts invitation](c_useCaseAcceptInviteExistingUser)

* [User declines invitation](c_useCaseDeclineInvite)

* [Accept or decline errors](c_acceptOrDeclineErrors)

* **[New user accepts invitation](c_useCaseAcceptInviteNewUser)**

* **[Existing user accepts invitation](c_useCaseAcceptInviteExistingUser)**

* **[User declines invitation](c_useCaseDeclineInvite)**

* **[Accept or decline errors](c_acceptOrDeclineErrors)**

**Parent topic:**[Account Association & Management Processes](../images/c_accountProcesses)


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