Skip to content

Commit bad786a

Browse files
docs: fixes DOC-38 (#3879)
* fixes DOC-38 * fix issues caused by pnpm format * minor change to restart build * minor update to push a change * fix links * docs: feedback updates
1 parent 8b5b23c commit bad786a

10 files changed

Lines changed: 223 additions & 117 deletions

File tree

packages/documentation/astro.config.mjs

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -181,12 +181,16 @@ export default defineConfig({
181181
label: 'Integration',
182182
collapsed: true,
183183
items: [
184+
{
185+
label: 'Overview',
186+
link: '/integration/overview'
187+
},
184188
{
185189
label: 'Requirements',
186190
collapsed: true,
187191
items: [
188192
{
189-
label: 'Overview and checklist',
193+
label: 'Integration checklist',
190194
link: '/integration/requirements/overview'
191195
},
192196
{
222 KB
Loading

packages/documentation/src/content/docs/admin/admin-user-guide.mdx

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -116,7 +116,7 @@ Ory Kratos provides frontend components (such as forms and buttons) for identity
116116
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.
117117
:::
118118

119-
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.
119+
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.
120120

121121
<LargeImg
122122
src='/img/admin-guide/home.png'

packages/documentation/src/content/docs/apis/graphql/admin-api-overview.mdx

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -16,7 +16,7 @@ This API is complemented by the Rafiki Admin app, a frontend interface for Rafik
1616

1717
## Auth Admin API
1818

19-
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 grantees account. The API also allows you to revoke grants.
19+
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.
2020

2121
## Idempotency
2222

Lines changed: 54 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,54 @@
1+
---
2+
title: Integrate Rafiki with your ASE
3+
---
4+
5+
import { Card, CardGrid, Badge } from '@astrojs/starlight/components'
6+
7+
## Before you begin
8+
9+
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.
10+
11+
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.
12+
13+
## Software components
14+
15+
<CardGrid>
16+
17+
<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>
18+
19+
<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>
20+
21+
<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>
22+
23+
</CardGrid>
24+
25+
## Integration steps
26+
27+
<CardGrid>
28+
<Card title="Integration checklist" icon="approve-check"> Review the integration checklist for more required and optional steps.<p></p><p>[Review the checklist >](/integration/requirements/overview)</p></Card>
29+
30+
<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>
31+
32+
<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>
33+
34+
<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>
35+
36+
<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 by calling/interfacing with the Backend Admin API. For example, deposit or withdraw liquidity.<p></p><p>[Specify a webhook endpoint >](/integration/requirements/webhook-events)</p></Card>
37+
38+
</CardGrid>
39+
40+
## Payments
41+
42+
The following steps illustrate how to make a basic payment between two wallet addresses on the same Rafiki instance.
43+
44+
<CardGrid>
45+
46+
<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>
47+
48+
<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>
49+
50+
<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>
51+
52+
<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>
53+
54+
</CardGrid>
Lines changed: 121 additions & 77 deletions
Original file line numberDiff line numberDiff line change
@@ -1,82 +1,126 @@
11
---
2-
title: Requirements overview and integration checklist
2+
title: Integration checklist
3+
head:
4+
- tag: style
5+
content: table, tr, td {background-color:transparent !important;} table {box-shadow:none !important;}
36
---
47

5-
import { Badge } from '@astrojs/starlight/components'
8+
import { Badge, Icon } from '@astrojs/starlight/components'
69
import { LinkOut } from '@interledger/docs-design-system'
710

8-
You must meet the following requirements before you deploy Rafiki to a production environment.
9-
10-
## Be an account servicing entity <Badge text="Required" variant="danger" />
11-
12-
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.
13-
14-
Rafiki shouldn't be used in production by non-regulated entities.
15-
16-
## Configure multi-tenancy <Badge text="Required" variant="danger" />
17-
18-
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.
19-
20-
[Manage tenants](/integration/requirements/tenants)
21-
22-
## Support at least one asset <Badge text="Required" variant="danger" />
23-
24-
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).
25-
26-
[Set up your assets](/integration/requirements/assets)
27-
28-
## Associate each user-facing payment account with a wallet address <Badge text="Required" variant="danger" />
29-
30-
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.
31-
32-
[Set up your wallet addresses](/integration/requirements/wallet-addresses)
33-
34-
## Expose a webhook endpoint and react to events accordingly <Badge text="Required" variant="danger" />
35-
36-
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).
37-
38-
[Specify your webhook endpoint and learn how to handle each event](/integration/requirements/webhook-events)
39-
40-
## Expose an exchange rate endpoint <Badge text="Conditionally Optional" variant="caution" />
41-
42-
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.
43-
44-
[Specify your exchange rate endpoint](/integration/requirements/exchange-rates)
45-
46-
## Define your sending fees <Badge text="Optional" variant="success" />
47-
48-
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.
49-
50-
[Define your sending fees](/integration/requirements/sending-fees)
51-
52-
## Add a peer to enable Interledger payments <Badge text="Conditionally Optional" variant="caution" />
53-
54-
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.
55-
56-
If you are using Rafiki solely for transfers between accounts on your ledger, peers aren't required.
57-
58-
[Add peers to your Rafiki instance](/integration/requirements/peers)
59-
60-
## Integrate with an identity provider (IdP) <Badge text="Conditionally Optional" variant="caution" />
61-
62-
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.
63-
64-
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.
65-
66-
[Integrate Rafiki with your IdP](/integration/requirements/open-payments/idp)
67-
68-
## Integration checklist
69-
70-
Ensure you've completed the following tasks before you deploy Rafiki to a production environment and join the Interledger network.
71-
72-
- [ ] You are a licensed financial account servicing entity in the jurisdictions you operate in
73-
- [ ] You have generated a UUID v4 for `OPERATOR_TENANT_ID` and a strong, random `ADMIN_API_SECRET`
74-
- [ ] You are HMAC-signing Backend Admin API requests (HMAC SHA-256) and include `tenant-id` and `signature` headers
75-
- [ ] You have established a secure, out-of-band process to deliver tenant credentials (`id` and `apiSecret`) to each tenant after creation
76-
- [ ] You have added at least one asset, either through the Backend Admin API or the Rafiki Admin app
77-
- [ ] You have implemented a strategy for creating wallet addresses for your account holders
78-
- [ ] You have set up your webhook endpoint and understand how to handle each webhook event
79-
- [ ] You have set up your exchange rates endpoint
80-
- [ ] 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
81-
- [ ] If supporting Open Payments outgoing payments, you have integrated with an IdP and configured the user consent screen and interaction flow
82-
- [ ] Your admin services are secured from external access
11+
## Required
12+
13+
Before deploying Rafiki to a production environment and joining the Interledger network, ensure you:
14+
15+
<table>
16+
<tr>
17+
<td>&#x2705;</td>
18+
<td>
19+
Are a licensed financial account servicing entity (ASE) in the
20+
jurisdictions you operate in
21+
</td>
22+
</tr>
23+
<tr>
24+
<td>&#x2705;</td>
25+
<td>
26+
Generate a UUID v4 for your operator tenant ID and a strong, random admin
27+
API secret
28+
</td>
29+
</tr>
30+
<tr>
31+
<td>&#x2705;</td>
32+
<td>
33+
You are HMAC-signing Backend Admin API requests (HMAC SHA-256) and include
34+
tenant ID and signature headers
35+
</td>
36+
</tr>
37+
<tr>
38+
<td>&#x2705;</td>
39+
<td>
40+
Establish a secure, out-of-band process to deliver tenant IDs and API
41+
secrets to each tenant after creation
42+
</td>
43+
</tr>
44+
<tr>
45+
<td>&#x2705;</td>
46+
<td>
47+
Add at least one asset, either through the Backend Admin API or the Rafiki
48+
Admin app
49+
</td>
50+
</tr>
51+
<tr>
52+
<td>&#x2705;</td>
53+
<td>
54+
Implement a strategy for creating wallet addresses for your account
55+
holders
56+
</td>
57+
</tr>
58+
<tr>
59+
<td>&#x2705;</td>
60+
<td>
61+
Set up your webhook endpoint and understand how to handle each webhook
62+
event
63+
</td>
64+
</tr>
65+
<tr>
66+
<td>&#x2705;</td>
67+
<td>Secure your admin services from external access</td>
68+
</tr>
69+
</table>
70+
71+
## Optional
72+
73+
<table>
74+
<tr>
75+
<td>&#x2705;</td>
76+
<td>
77+
**Integrate with an identity provider (IdP)**
78+
<p>
79+
If you plan to use the authorization server provided through Rafiki's
80+
Auth service, and/or support Open Payments outgoing payments, you
81+
**must** [integrate with an
82+
IdP](/integration/requirements/open-payments/idp). An IdP is a system or
83+
service that stores and manages user identity information,
84+
authentication, and consent for an ASE's users.
85+
</p>
86+
</td>
87+
</tr>
88+
<tr>
89+
<td>&#x2705;</td>
90+
<td>
91+
**Add a peer**
92+
<p>
93+
A peer is another ASE that you connect with via Interledger who is
94+
likely running their own Rafiki instance. If you are using Rafiki solely
95+
for transfers between accounts on your own ledger, peers aren't
96+
required. Otherwise, you must [add at least one
97+
peer](/integration/requirements/peers) to enable Interledger payments on
98+
your accounts.
99+
</p>
100+
</td>
101+
</tr>
102+
<tr>
103+
<td>&#x2705;</td>
104+
<td>
105+
**Set up your exchange rates endpoint**
106+
<p>
107+
If you plan to support cross-currency transactions, you must [specify
108+
the endpoint](/integration/requirements/exchange-rates) from where your
109+
Rafiki instance will fetch current exchange rates. Exchange rates are
110+
calculated as part of a payment's quote, which estimates the full cost
111+
of transferring value over the network.
112+
</p>
113+
</td>
114+
</tr>
115+
<tr>
116+
<td>&#x2705;</td>
117+
<td>
118+
**Define your sending fee**
119+
<p>
120+
You can [charge a sending fee](/integration/requirements/sending-fees),
121+
on top of any estimated network fees, for facilitating transfers. Each
122+
asset you support can have a different fee structure.
123+
</p>
124+
</td>
125+
</tr>
126+
</table>

packages/documentation/src/content/docs/overview/concepts/account-servicing-entity.mdx

Lines changed: 9 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -8,30 +8,20 @@ As regulated entities, ASEs are subject to the laws, rules, and regulations of t
88

99
## Responsibilities and obligations
1010

11-
A few examples of an ASE's responsibilities and obligations include:
11+
<img src='/img/ase-responsibilites.png' alt='' style='max-width:600px' />
1212

13-
- Regulatory compliance
14-
- Account provisioning and maintenance
15-
- Transaction handling
16-
- Ledger management
17-
- Authentication and consent
13+
### AML (Anti-money laundering)
1814

19-
### Regulatory compliance
15+
ASEs follow anti-money laundering laws and regulations to detect and prevent money laundering and other suspicious financial activities.
2016

21-
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.
17+
### KYC/KYB (Know your customer/business)
2218

23-
### Account provisioning and maintenance
19+
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.
2420

25-
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.
21+
### User account management
2622

27-
### Transaction handling
23+
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.
2824

29-
ASEs handle deposits and withdrawals through various external payment methods such as bank transfers, credit cards, and other payment services.
25+
### Ledger
3026

31-
### Ledger management
32-
33-
ASEs maintain a ledger of account balances and transaction histories for their account holders.
34-
35-
### Authentication and consent
36-
37-
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).
27+
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.

0 commit comments

Comments
 (0)