docs: fixes #3388 (#3395)

melissahenderson · web-flow · commit e95b9e638b74 · 2025-04-15T07:26:28.000-04:00
diff --git a/packages/documentation/src/content/docs/integration/playground/overview.mdx b/packages/documentation/src/content/docs/integration/playground/overview.mdx
@@ -269,38 +269,38 @@ The Examples folder in the Bruno collection includes an [Open Payments](https://
 
 <Mermaid
   graph={`sequenceDiagram
-    participant B as Bruno Client
-    participant SW as Sender Wallet
-    participant RW as Receiver Wallet
-    participant AS as Auth Server
-    participant IdP as Identity Provider
+    participant B as Bruno client
+    participant SW as Sender's wallet
+    participant RW as Recipient's wallet
+    participant AS as Authorization server
+    participant IdP as Identity provider
 
     B->>SW: 1. GET wallet address
     SW-->>B: 200 OK (authServer URL)
 
     B->>RW: 2. GET wallet address
     RW-->>B: 200 OK (authServer URL)
 
-    Note over B,AS: Non-interactive grant
+    Note over B,AS: Non-interactive grant for incoming payment resource
     B->>AS: 3. POST grant request (incoming-payment)
     AS-->>B: 200 OK (accessToken)
 
     B->>RW: 4. POST /incoming-payments
     RW-->>B: 201 Created (incomingPaymentId)
 
-    Note over B,AS: Non-interactive grant
+    Note over B,AS: Non-interactive grant for quote resource
     B->>AS: 5. POST grant request (quote)
     AS-->>B: 200 OK (accessToken)
 
     B->>SW: 6. POST /quotes
     SW-->>B: 201 Created (quoteId)
 
-    Note over B,AS: Interactive grant required
+    Note over B,AS: Interactive grant required for outgoing payment resource
     B->>AS: 7. POST grant request (outgoing-payment)
     AS-->>B: 200 OK (redirect_uri)
 
     rect rgb(240, 240, 240)
-        Note over B,AS: Interactive Authorization<br/>User interaction required for outgoing payment grants
+        Note over B,AS: Interactive authorization<br/>User interaction required to obtain consent
         B->>IdP: Redirect for user consent
         IdP-->>B: User consents
         B->>AS: 8. POST /continue/{continueId}
diff --git a/packages/documentation/src/content/docs/integration/requirements/assets.mdx b/packages/documentation/src/content/docs/integration/requirements/assets.mdx
@@ -6,7 +6,7 @@ tableOfContents:
 
 import { Tabs, TabItem } from '@astrojs/starlight/components'
 import { Badge } from '@astrojs/starlight/components'
-import { Mermaid, CodeBlock, LinkOut } from '@interledger/docs-design-system'
+import { CodeBlock, LinkOut } from '@interledger/docs-design-system'
 
 An asset represents an item of value that can be transferred via the Interledger Protocol. Assets in Rafiki can be added through the Backend Admin API or the [Rafiki Admin](/admin/admin-user-guide/#assets) application.
 
diff --git a/packages/documentation/src/content/docs/integration/requirements/exchange-rates.mdx b/packages/documentation/src/content/docs/integration/requirements/exchange-rates.mdx
@@ -3,7 +3,7 @@ title: Exchange rates
 ---
 
 import { Badge } from '@astrojs/starlight/components'
-import { Mermaid, CodeBlock, LinkOut } from '@interledger/docs-design-system'
+import { CodeBlock, LinkOut } from '@interledger/docs-design-system'
 
 If you plan to support cross-currency transactions, you must specify from where your Rafiki instance will fetch current exchange rates.
 
diff --git a/packages/documentation/src/content/docs/integration/requirements/open-payments/grants-revoking.mdx b/packages/documentation/src/content/docs/integration/requirements/open-payments/grants-revoking.mdx
@@ -3,7 +3,7 @@ title: Viewing and revoking grants
 ---
 
 import { Badge, Tabs, TabItem } from '@astrojs/starlight/components'
-import { Mermaid, CodeBlock, LinkOut } from '@interledger/docs-design-system'
+import { CodeBlock, LinkOut } from '@interledger/docs-design-system'
 
 Grants are the mechanism in Open Payments by which your account holders give permission to a client application to access their accounts and send payments on their behalf. Providing your account holders the ability to view and revoke grants is not required to implement and operate Rafiki, but allowing them to do so is critical to providing an optimal user experience.
 
diff --git a/packages/documentation/src/content/docs/integration/requirements/open-payments/idp.mdx b/packages/documentation/src/content/docs/integration/requirements/open-payments/idp.mdx
@@ -3,12 +3,7 @@ title: Identity provider (IdP)
 ---
 
 import { Badge, Steps } from '@astrojs/starlight/components'
-import {
-  Mermaid,
-  MermaidWrapper,
-  LinkOut,
-  CodeBlock
-} from '@interledger/docs-design-system'
+import { LinkOut, CodeBlock } from '@interledger/docs-design-system'
 
 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.
 
diff --git a/packages/documentation/src/content/docs/integration/requirements/sending-fees.mdx b/packages/documentation/src/content/docs/integration/requirements/sending-fees.mdx
@@ -6,7 +6,7 @@ tableOfContents:
 
 import { Tabs, TabItem } from '@astrojs/starlight/components'
 import { Badge } from '@astrojs/starlight/components'
-import { Mermaid, CodeBlock, LinkOut } from '@interledger/docs-design-system'
+import { CodeBlock, LinkOut } from '@interledger/docs-design-system'
 
 You have the option to charge sending fees, on top of any estimated network fees, for facilitating transfers. Each asset you support can have a different fee structure and you can specify both fixed and variable fees per asset. The fee amount is added on top of the quote that is generated after the ILP rate probe completes. You can define sending fees through the Backend Admin API or the [Rafiki Admin](/admin/admin-user-guide/#edit-asset) application.
 
diff --git a/packages/documentation/src/content/docs/integration/requirements/webhook-events.mdx b/packages/documentation/src/content/docs/integration/requirements/webhook-events.mdx
@@ -269,7 +269,8 @@ of $10 was completed.
       participant ASE as Account servicing entity
 
       R->>ASE: Fires incoming_payment.completed event to webhook endpoint,<br/>receivedAmount: $10
-      ASE->>R: Backend Admin API call: CreateIncomingPaymentWithdrawal
+      ASE->>R: Backend Admin API call: createIncomingPaymentWithdrawal
+      R-->>ASE: success: true
       ASE->>ASE: Credit recipient's account with $10
 
 `}
@@ -286,9 +287,11 @@ of $10 was completed.
       participant ASE as Account servicing entity
 
       R->>ASE: Fires incoming_payment.completed event to webhook endpoint,<br/>receivedAmount: $10
-      ASE->>R: Backend Admin API call: CreateIncomingPaymentWithdrawal
+      ASE->>R: Backend Admin API call: createIncomingPaymentWithdrawal
+      R-->>ASE: success: true
       ASE->>ASE: Credit recipient's account with $10
-      ASE->>R: Backend Admin API call: PostLiquidityWithdrawal
+      ASE->>R: Backend Admin API call: postLiquidityWithdrawal
+      R-->>ASE: success: true
       R->>R: Two-phase transfer completed
 
 `}
@@ -310,7 +313,8 @@ The `incoming_payment.completed` event indicates the payment completed either au
       participant ASE as Account servicing entity
 
       R->>ASE: Fires incoming_payment.expired event to webhook endpoint,<br/>receivedAmount: $2.55
-      ASE->>R: Backend Admin API call: CreateIncomingPaymentWithdrawal
+      ASE->>R: Backend Admin API call: createIncomingPaymentWithdrawal
+      R-->>ASE: success: true
       ASE->>ASE: Credit recipient's account with $2.55
 
 `}
@@ -353,9 +357,11 @@ An outgoing payment for \$12 was created.
       ASE->>ASE: Checks that sender's account has sufficient funds
       alt Account has sufficient funds
         ASE->>ASE: Put hold of $12 on sender's account
-        ASE->>R: Backend Admin API call: DepositOutgoingPaymentLiquidity
+        ASE->>R: Backend Admin API call: depositOutgoingPaymentLiquidity
+        R-->>ASE: success: true
       else Account has insufficient funds
-        ASE->>R: Backend Admin API call: CancelOutgoingPayment,<br/>reason: Insufficient funds
+        ASE->>R: Backend Admin API call: cancelOutgoingPayment,<br/>Reason: insufficient funds
+        R-->>ASE: success: true
       end
 
 `}
@@ -382,7 +388,8 @@ for \$12 is complete. \$11.50 was sent. You choose to keep \$0.50 as a service f
       participant ASE as Account servicing entity
 
       R->>ASE: Fires outgoing_payment.completed event to webhook endpoint,<br/>debitAmount: $12, sentAmount: $11.50
-      ASE->>R: Backend Admin API call: CreateOutgoingPaymentWithdrawal
+      ASE->>R: Backend Admin API call: createOutgoingPaymentWithdrawal
+      R-->>ASE: success: true
       ASE->>ASE: Remove hold and deduct $12 from sender's account,<br/>credit your account with $0.50
 
 `}
@@ -396,9 +403,11 @@ for \$12 is complete. \$11.50 was sent. You choose to keep \$0.50 as a service f
       participant ASE as Account servicing entity
 
       R->>ASE: Fires outgoing_payment.completed event to webhook endpoint,<br/>debitAmount: $12, sentAmount: $11.50
-      ASE->>R: Backend Admin API call: CreateOutgoingPaymentWithdrawal
+      ASE->>R: Backend Admin API call: createOutgoingPaymentWithdrawal
+      R-->>ASE: success: true
       ASE->>ASE: Remove hold and deduct $12 from sender's account,<br/>credit your account with $0.50
-      ASE->>R: Backend Admin API call: PostLiquidityWithdrawal
+      ASE->>R: Backend Admin API call: postLiquidityWithdrawal
+      R-->>ASE: success: true
       R->>R: Two-phase transfer complete
 
 `}
@@ -422,7 +431,8 @@ An outgoing payment for \$12 failed. \$8 was sent successfully.
       participant ASE as Account servicing entity
 
       R->>ASE: Fires outgoing_payment.failed event to webhook endpoint,<br/>debitAmount: $12, sentAmount: $8
-      ASE->>R: Backend Admin API call: CreateOutgoingPaymentWithdrawal
+      ASE->>R: Backend Admin API call: createOutgoingPaymentWithdrawal
+      R-->>ASE: success: true
       ASE->>ASE: Remove hold and deduct $8 from the sender's account
 
 `}
@@ -455,7 +465,8 @@ The wallet address, `https://wallet.example.com/carla_garcia` was requested but
       participant ASE as Account servicing entity
 
       R->>ASE: Fires wallet_address.not_found event to webhook endpoint,<br/>wallet address: https://wallet.example.com/carla_garcia
-      ASE->>R: Backend Admin API call: CreateWalletAddress,<br/>url: https://wallet.example.com/carla_garcia,<br/>public name: Carla Eva Garcia
+      ASE->>R: Backend Admin API call: createWalletAddress,<br/>url: https://wallet.example.com/carla_garcia,<br/>public name: Carla Eva Garcia
+      R-->>ASE: success: true
 
 `}
 />
@@ -486,7 +497,8 @@ A wallet address received a Web Monetization payment of \$0.33
       participant ASE as Account servicing entity
 
       R->>ASE: Fires wallet_address.web_monetization event to webhook endpoint,<br/>receivedAmount: $0.33
-      ASE->>R: Backend Admin API call: CreateWalletAddressWithdrawal
+      ASE->>R: Backend Admin API call: createWalletAddressWithdrawal
+      R-->>ASE: success: true
       ASE->>ASE: Credit recipient's account with $0.33
 
 `}
@@ -518,7 +530,8 @@ Your asset liquidity for USD (asset scale: 2) drops below \$100.00.
       participant ASE as Account servicing entity
 
       R->>ASE: Fires asset.liquidity_low event to webhook endpoint,<br/>asset: USD (scale: 2, id: "abc")
-      ASE->>R: Backend Admin API call: DepositAssetLiquidity
+      ASE->>R: Backend Admin API call: depositAssetLiquidity
+      R-->>ASE: success: true
 
 `}
 />
@@ -549,7 +562,8 @@ The liquidity for your peer, Happy Life Bank, drops below \$100.00 USD.
       participant ASE as Account servicing entity
 
       R->>ASE: Fires peer.liquidity_low event to webhook endpoint,<br/>peer: Happy Life Bank (asset: "USD", scale: 2, id: "abc")
-      ASE->>R: Backend Admin API call: DepositPeerLiquidity
+      ASE->>R: Backend Admin API call: depositPeerLiquidity
+      R-->>ASE: success: true
 
 `}
 />
diff --git a/packages/documentation/src/content/docs/overview/concepts/accounting.mdx b/packages/documentation/src/content/docs/overview/concepts/accounting.mdx
@@ -250,7 +250,7 @@ A two-phase transfer moves funds in two stages.
 <Mermaid
   graph={`sequenceDiagram
     Rafiki->>ASE: Fires webhook event when incoming payment completes
-    ASE->>Rafiki: Withdraws payment amount from incoming payment liquidity account (reserve funds pending)
+    ASE->>Rafiki: Withdraws payment amount from incoming payment<br />liquidity account (reserve funds pending)
     ASE->>ASE: Credits the recipient's account by the payment amount
     ASE->>Rafiki: Resolve funds (post)
     Rafiki->>Rafiki: Two-phase transfer complete
