interledger · melissahenderson · Apr 2, 2026 · Apr 2, 2026 · Apr 2, 2026 · Apr 3, 2026
diff --git a/packages/documentation/astro.config.mjs b/packages/documentation/astro.config.mjs
@@ -181,12 +181,16 @@ export default defineConfig({
           label: 'Integration',
           collapsed: true,
           items: [
+            {
+              label: 'Overview',
+              link: '/integration/overview'
+            },
             {
               label: 'Requirements',
               collapsed: true,
               items: [
                 {
-                  label: 'Overview and checklist',
+                  label: 'Integration checklist',
                   link: '/integration/requirements/overview'
                 },
                 {

diff --git a/packages/documentation/public/img/ase-responsibilites.png b/packages/documentation/public/img/ase-responsibilites.png
diff --git a/packages/documentation/src/content/docs/admin/admin-user-guide.mdx b/packages/documentation/src/content/docs/admin/admin-user-guide.mdx
@@ -116,7 +116,7 @@ Ory Kratos provides frontend components (such as forms and buttons) for identity
 The screenshots in this guide may not perfectly reflect the appearance of the Rafiki Admin UI in all environments. Specifically, the left navigation menu can differ slightly depending on whether authentication via Kratos is enabled.
 :::
 
-After logging in, you'll be greeted by the main landing page with a left-hand navigation menu. This menu provides access to the main functionality needed to manage your Rafiki instance.
+After logging in, you'll be greeted by the main landing page with a left-hand navigation menu. This menu provides access to the main capabilities needed to manage your Rafiki instance.
 
 <LargeImg
   src='/img/admin-guide/home.png'

diff --git a/packages/documentation/src/content/docs/apis/graphql/admin-api-overview.mdx b/packages/documentation/src/content/docs/apis/graphql/admin-api-overview.mdx
@@ -16,7 +16,7 @@ This API is complemented by the Rafiki Admin app, a frontend interface for Rafik
 
 ## Auth Admin API
 
-The Auth Admin API allows you to get information about a grant, such as its status, state, related payment details, and the wallet address of the grantee’s account. The API also allows you to revoke grants.
+The Auth Admin API allows you to get information about a grant, such as its status, state, related payment details, and the wallet address of the grantee's account. The API also allows you to revoke grants.
 
 ## Idempotency
 

diff --git a/packages/documentation/src/content/docs/integration/overview.mdx b/packages/documentation/src/content/docs/integration/overview.mdx
@@ -0,0 +1,53 @@
+---
+title: Integrate Rafiki with your ASE
+---
+
+import { Card, CardGrid, Badge } from '@astrojs/starlight/components'
+
+## Before you begin
+
+You must be, or be working with, an account servicing entity (ASE). An ASE is an entity that provides and maintains payment accounts for its customers and is regulated in the jurisdictions it operates. Examples of ASEs include banks, digital wallet providers, and mobile money providers. The [account servicing entity](/overview/concepts/account-servicing-entity) page provides examples of an ASE's responsibilities and obligations.
+
+For testing purposes, you can set up a [mock account servicing entity](/integration/playground/overview) that's deployed Rafiki. However, Rafiki **should not** be used in production environments by non-regulated ASEs.
+
+## Software components
+
+<CardGrid>
+
+  <Card title="Auth service"> The Auth service hosts the Open Payments authorization server. Integration with this service is required if you don't develop your own in-house service for authorization.<p></p><p>[Learn more >](/integration/deployment/services/auth-service)</p></Card>
+
+  <Card title="Backend service"> The Backend service hosts the Open Payments resource server, ILP connector, and Backend Admin API.<p></p><p>[Learn more >](/integration/deployment/services/backend-service)</p></Card>
+
+  <Card title="Frontend service"> The Frontend service offers an optional administrative user interface for interacting with the Backend Admin API.<p></p><p>[Learn more >](/integration/deployment/services/frontend-service)</p></Card>
+
+</CardGrid>
+
+## Integration steps
+
+<CardGrid>
+
+  <Card title="Tenants"><Badge text="Required" variant="danger" /> A tenant represents an isolated environment for an ASE. You must create a tenant even if you don't intend to share your Rafiki instance across ASEs.<p></p><p>[Create a tenant >](/integration/requirements/tenants)</p></Card>
+
+  <Card title="Assets"><Badge text="Required" variant="danger" /> An asset is a monetary unit represented by a currency code and a scale. Rafiki must be set up for at least one asset.<p></p><p>[Create an asset >](/integration/requirements/assets)</p></Card>
+
+  <Card title="Wallet addresses"><Badge text="Required" variant="danger" /> Each payment account in the ASE's system must be linked to a wallet address. You must have at least one asset in Rafiki before creating wallet addresses.<p></p><p>[Create a wallet address >](/integration/requirements/wallet-addresses)</p></Card>
+
+  <Card title="Webhook endpoint"><Badge text="Required" variant="danger" /> You must expose a webhook endpoint that listens for events dispatched by Rafiki, then react accordingly. For example, deposit or withdraw liquidity.<p></p><p>[Specify a webhook endpoint >](/integration/requirements/webhook-events)</p></Card>
+
+  <Card title="Integration checklist"> Review the integration checklist for more required and optional steps.<p></p><p>[Review the checklist >](/integration/requirements/overview)</p></Card>
+
+</CardGrid>
+
+## Payments
+
+<CardGrid>
+
+  <Card title="1. Create an incoming payment"> Use the Backend Admin API's `createIncomingPayment` to create an incoming payment resource on the recipient's wallet account.<p></p><p>[createIncomingPayment mutation >](https://rafiki.dev/apis/graphql/backend#mutation-createIncomingPayment)</p></Card>
+
+  <Card title="2. Create a quote"> Use the Backend Admin API's `createQuote` to create a quote resource on the sender's wallet account. The quote shows how much it will cost the sender to deliver an amount to the receiver.<p></p><p>[createQuote mutation >](https://rafiki.dev/apis/graphql/backend#mutation-createQuote)</p></Card>
+
+  <Card title="3. Create an outgoing payment"> Use the Backend Admin API's `createOutgoingPayment` to create an outgoing payment resource on the sender's wallet account. This operations starts the payment. At this point, the sender's ASE must fund/approve the payment before it sends.<p></p><p>[createOutgoingPayment mutation >](https://rafiki.dev/apis/graphql/backend#mutation-createOutgoingPayment)</p></Card>
+
+  <Card title="Handle webhook requests"> As the payment flow progresses, the ASE is be notified about events that happen in the system. Some events are actionable, such as an `outgoing_payment.created` event. Review the webhook events page to learn more about handling each event.<p></p><p>[Webhook events >](/integration/requirements/webhook-events)</p></Card>
+
+</CardGrid>
diff --git a/packages/documentation/src/content/docs/integration/requirements/overview.mdx b/packages/documentation/src/content/docs/integration/requirements/overview.mdx
@@ -1,82 +1,127 @@
 ---
-title: Requirements overview and integration checklist
+title: Integration checklist
+head:
+  - tag: style
+    content: table, tr, td {background-color:transparent !important;} table {box-shadow:none !important;}
 ---
 
-import { Badge } from '@astrojs/starlight/components'
+import { Badge, Icon } from '@astrojs/starlight/components'
 import { LinkOut } from '@interledger/docs-design-system'
 
-You must meet the following requirements before you deploy Rafiki to a production environment.
-
-## Be an account servicing entity <Badge text="Required" variant="danger" />
-
-An account servicing entity (ASE) is an entity that provides and maintains payment accounts for its customers and is regulated in the jurisdictions it operates. Examples of ASEs include banks, digital wallet providers, and mobile money providers. The [account servicing entity](/overview/concepts/account-servicing-entity) page provides examples of an ASE's responsibilities and obligations.
-
-Rafiki shouldn't be used in production by non-regulated entities.
-
-## Configure multi-tenancy <Badge text="Required" variant="danger" />
-
-You must configure multi‑tenancy by establishing the operator and enabling tenant‑scoped access. Generate a UUID v4 for `OPERATOR_TENANT_ID` and a strong, random `ADMIN_API_SECRET`, and plan a secure out‑of‑band process to deliver each tenant’s `id` and `apiSecret` after creation.
-
-[Manage tenants](/integration/requirements/tenants)
-
-## Support at least one asset <Badge text="Required" variant="danger" />
-
-You must set up Rafiki to support at least one asset. An asset in Rafiki represents an item of value that can be transferred via the Interledger Protocol. Since the Interledger Protocol aims to create an internet of value, it allows for the transfer of any asset, not just currency. In practice, however, assets are usually denominated in a currency (fiat or branded currencies).
-
-[Set up your assets](/integration/requirements/assets)
-
-## Associate each user-facing payment account with a wallet address <Badge text="Required" variant="danger" />
-
-A wallet address is a publicly shareable standardized ID for a payment account. Each payment account belonging to your users (for example, your customers) must have at least one associated wallet address for the account to be able to send and/or receive payments via Open Payments and Interledger.
-
-[Set up your wallet addresses](/integration/requirements/wallet-addresses)
-
-## Expose a webhook endpoint and react to events accordingly <Badge text="Required" variant="danger" />
-
-The main communication channel between you and your Rafiki instance is composed of the Backend Admin API and a set of webhook events. Most of these events require you to interact with Rafiki. You must expose a webhook endpoint that listens for events dispatched by Rafiki, then react accordingly (for example, deposit or withdraw liquidity).
-
-[Specify your webhook endpoint and learn how to handle each event](/integration/requirements/webhook-events)
-
-## Expose an exchange rate endpoint <Badge text="Conditionally Optional" variant="caution" />
-
-If you plan to support cross-currency transactions, you must specify from where your Rafiki instance will fetch current exchange rates. Exchange rates are calculated as part of a payment's quote, which estimates the full cost of transferring value over the network.
-
-[Specify your exchange rate endpoint](/integration/requirements/exchange-rates)
-
-## Define your sending fees <Badge text="Optional" variant="success" />
-
-You have the option to charge a sending fee, on top of any estimated network fees, for facilitating transfers. Each asset you support can have a different fee structure.
-
-[Define your sending fees](/integration/requirements/sending-fees)
-
-## Add a peer to enable Interledger payments <Badge text="Conditionally Optional" variant="caution" />
-
-You must add one or more peers if you intend to enable Interledger payments on your accounts. A peer is another ASE that you connect with via Interledger and is likely running their own Rafiki instance.
-
-If you are using Rafiki solely for transfers between accounts on your ledger, peers aren't required.
-
-[Add peers to your Rafiki instance](/integration/requirements/peers)
-
-## Integrate with an identity provider (IdP) <Badge text="Conditionally Optional" variant="caution" />
-
-An identity provider (IdP) is a system or service that stores and manages user identity information, authentication, and consent. Examples of IdPs include OpenID Connect and Okta.
-
-You must integrate with an IdP if you plan to use the authorization server provided through Rafiki's auth service. The authorization server requires consent be collected via an interactive grant before an outgoing payment request is issued. The purpose of the IdP is to handle the authentication and consent required to authorize the interactive grant request.
-
-[Integrate Rafiki with your IdP](/integration/requirements/open-payments/idp)
-
-## Integration checklist
-
-Ensure you've completed the following tasks before you deploy Rafiki to a production environment and join the Interledger network.
-
-- [ ] You are a licensed financial account servicing entity in the jurisdictions you operate in
-- [ ] You have generated a UUID v4 for `OPERATOR_TENANT_ID` and a strong, random `ADMIN_API_SECRET`
-- [ ] You are HMAC-signing Backend Admin API requests (HMAC SHA-256) and include `tenant-id` and `signature` headers
-- [ ] You have established a secure, out-of-band process to deliver tenant credentials (`id` and `apiSecret`) to each tenant after creation
-- [ ] You have added at least one asset, either through the Backend Admin API or the Rafiki Admin app
-- [ ] You have implemented a strategy for creating wallet addresses for your account holders
-- [ ] You have set up your webhook endpoint and understand how to handle each webhook event
-- [ ] You have set up your exchange rates endpoint
-- [ ] You have defined the sending fee you will charge, if any, for each asset, either through the Backend Admin API or the Rafiki Admin app
-- [ ] If supporting Open Payments outgoing payments, you have integrated with an IdP and configured the user consent screen and interaction flow
-- [ ] Your admin services are secured from external access
+## Required
+
+Before deploying Rafiki to a production environment and joining the Interledger network, ensure you:
+
+<table>
+  <tr>
+    <td>&#x2705;</td>
+    <td>
+      Are a licensed financial account servicing entity (ASE) in the
+      jurisdictions you operate in
+    </td>
+  </tr>
+  <tr>
+    <td>&#x2705;</td>
+    <td>
+      Generate a UUID v4 for your operator tenant ID and a strong, random admin
+      API secret
+    </td>
+  </tr>
+  <tr>
+    <td>&#x2705;</td>
+    <td>
+      You are HMAC-signing Backend Admin API requests (HMAC SHA-256) and include
+      tenant ID and signature headers
+    </td>
+  </tr>
+  <tr>
+    <td>&#x2705;</td>
+    <td>
+      Establish a secure, out-of-band process to deliver tenant IDs and API
+      secrets to each tenant after creation
+    </td>
+  </tr>
+  <tr>
+    <td>&#x2705;</td>
+    <td>
+      Add at least one asset, either through the Backend Admin API or the Rafiki
+      Admin app
+    </td>
+  </tr>
+  <tr>
+    <td>&#x2705;</td>
+    <td>
+      Implement a strategy for creating wallet addresses for your account
+      holders
+    </td>
+  </tr>
+  <tr>
+    <td>&#x2705;</td>
+    <td>
+      Set up your webhook endpoint and understand how to handle each webhook
+      event
+    </td>
+  </tr>
+  <tr>
+    <td>&#x2705;</td>
+    <td>Secure your admin services from external access</td>
+  </tr>
+</table>
+
+## Optional
+
+<table>
+  <tr>
+    <td>&#x2705;</td>
+    <td>
+      **Integrate with an identity provider (IdP)**
+      <p>
+        If you plan to use the authorization server provided through Rafiki's
+        Auth service, and/or support Open Payments outgoing payments, you
+        **must** [integrate with an
+        IdP](/integration/requirements/open-payments/idp). An IdP is a system or
+        service that stores and manages user identity information,
+        authentication, and consent. Examples of IdPs include OpenID Connect and
+        Okta.
+      </p>
+    </td>
+  </tr>
+  <tr>
+    <td>&#x2705;</td>
+    <td>
+      **Add a peer**
+      <p>
+        A peer is another ASE that you connect with via Interledger who is
+        likely running their own Rafiki instance. If you are using Rafiki solely
+        for transfers between accounts on your own ledger, peers aren't
+        required. Otherwise, you must [add at least one
+        peer](/integration/requirements/peers) to enable Interledger payments on
+        your accounts.
+      </p>
+    </td>
+  </tr>
+  <tr>
+    <td>&#x2705;</td>
+    <td>
+      **Set up your exchange rates endpoint**
+      <p>
+        If you plan to support cross-currency transactions, you must [specify
+        the endpoint](/integration/requirements/exchange-rates) from where your
+        Rafiki instance will fetch current exchange rates. Exchange rates are
+        calculated as part of a payment's quote, which estimates the full cost
+        of transferring value over the network.
+      </p>
+    </td>
+  </tr>
+  <tr>
+    <td>&#x2705;</td>
+    <td>
+      **Define your sending fee**
+      <p>
+        You can [charge a sending fee](/integration/requirements/sending-fees),
+        on top of any estimated network fees, for facilitating transfers. Each
+        asset you support can have a different fee structure.
+      </p>
+    </td>
+  </tr>
+</table>
diff --git a/...s/documentation/src/content/docs/overview/concepts/account-servicing-entity.mdx b/...s/documentation/src/content/docs/overview/concepts/account-servicing-entity.mdx
@@ -8,30 +8,20 @@ As regulated entities, ASEs are subject to the laws, rules, and regulations of t
 
 ## Responsibilities and obligations
 
-A few examples of an ASE's responsibilities and obligations include:
+<img src='/img/ase-responsibilites.png' alt='' style='max-width:600px' />
 
-- Regulatory compliance
-- Account provisioning and maintenance
-- Transaction handling
-- Ledger management
-- Authentication and consent
+### AML (Anti-money laundering)
 
-### Regulatory compliance
+ASEs follow anti-money laundering laws and regulations to detect and prevent money laundering and other suspicious financial activities.
 
-ASEs must onboard account holders in compliance with regulatory requirements, such as performing Know Your Customer (KYC) checks, anti-money laundering (AML) processes, and sanctions screening.
+### KYC/KYB (Know your customer/business)
 
-### Account provisioning and maintenance
+KYC and KYB practices ensure ASEs verify the identities of their customers by collecting IDs and proof of address, verifying business registrations, checking against sanctions lists, and other processes.
 
-ASEs manage the creation, upkeep, and security of payment accounts. This includes providing channels for account holders (individuals or businesses) to interact with their accounts via mobile apps, websites, and other interfaces.
+### User account management
 
-### Transaction handling
+ASEs manage the creation, upkeep, and security of their customers' accounts and balances therein. Similarly, they're responsible for authenticating their customers and providing secure channels for them to interact with their accounts via mobile apps, websites, or other interfaces.
 
-ASEs handle deposits and withdrawals through various external payment methods such as bank transfers, credit cards, and other payment services.
+### Ledger
 
-### Ledger management
-
-ASEs maintain a ledger of account balances and transaction histories for their account holders.
-
-### Authentication and consent
-
-In the context of Open Payments, ASEs are responsible for authenticating resource owners (for example, account holders) and obtaining their consent when clients, such as mobile apps, request access to a resource (for example, an account).
+As ASEs handle deposits and withdrawals through external payment methods (like bank transfers, credit cards, and other services) they must record all transactions and balance information in their ledger.