docs: fixing open payments links (#3462)

After restructuring the Open Payments docs, several of the links in the Rafiki docs would be broken without this fix

Author: brad-dow

packages/documentation/src/content/docs/integration/deployment/services/auth-service.mdx

@@ -32,7 +32,7 @@ When a request comes from a client with an account known to your local instance
 
 When a request comes from a client registered with another instance of Rafiki, the `auth` service resolves the client's key endpoint (for example, `https://wallet.example.com/alice/jwks.json`) to retrieve the client's public keys, then filters out the correct key using the key id (`kid`) in the client's signature.
 
-Review the <LinkOut href="https://openpayments.dev/introduction/client-keys/">Open Payments documentation</LinkOut> for more information about client keys.
+Review the <LinkOut href="https://openpayments.dev/identity/client-keys/">Open Payments documentation</LinkOut> for more information about client keys.
 
 ## Identity provider (IdP)
 
@@ -44,7 +44,7 @@ You must integrate with an [IdP](/integration/requirements/open-payments/idp) wh
 Rafiki’s [`frontend`](/integration/deployment/services/frontend-service) service requires an IdP for authentication and user management of your [Rafiki Admin](/admin/admin-user-guide) users. Out of the box, Rafiki uses Ory Kratos, a cloud-based user management system. Kratos is for internal use only and **cannot** be used as your customer-facing Open Payments authorization server.
 :::
 
-For more information about interactive grants and how they work with identity providers, review the [Identity Provider](/integration/requirements/open-payments/idp) page and the <LinkOut href="https://openpayments.dev/introduction/grants/">Grant negotiation and authorization</LinkOut> page in the Open Payments docs.
+For more information about interactive grants and how they work with identity providers, review the [Identity Provider](/integration/requirements/open-payments/idp) page and the <LinkOut href="https://openpayments.dev/identity/grants/">Grant negotiation and authorization</LinkOut> page in the Open Payments docs.
 
 ## GraphQL Auth Admin API
 

packages/documentation/src/content/docs/integration/deployment/services/backend-service.mdx

@@ -29,7 +29,7 @@ You must also set the environment variables for the `backend` service.
 
 The `backend` service exposes the Open Payments APIs, which are auth-protected using an opinionated version of the Grant Negotiation and Authorization Protocol (GNAP). Review the [`auth`](/integration/deployment/services/auth-service) service page for more details about grant authorization and authentication.
 
-The `backend` service allows you to manage Open Payments <LinkOut href="https://openpayments.dev/introduction/op-concepts/#incoming-payment">incoming payments</LinkOut>, <LinkOut href="https://openpayments.dev/introduction/op-concepts/#quote">quotes</LinkOut>, and <LinkOut href='https://openpayments.dev/introduction/op-concepts/#outgoing-payment'>outgoing payments</LinkOut>. Quotes and outgoing payments call the ILP connector, described in the next section, to send ILP packets. Quoting sends unfulfillable probe packets, for example to determine a transaction’s cost before executing the payment. Outgoing payments send packets as part of executing the payment.
+The `backend` service allows you to manage Open Payments <LinkOut href="https://openpayments.dev/concepts/resources/#incoming-payment">incoming payments</LinkOut>, <LinkOut href="https://openpayments.dev/concepts/resources/#quote">quotes</LinkOut>, and <LinkOut href='https://openpayments.dev/concepts/resources/#outgoing-payment'>outgoing payments</LinkOut>. Quotes and outgoing payments call the ILP connector, described in the next section, to send ILP packets. Quoting sends unfulfillable probe packets, for example to determine a transaction’s cost before executing the payment. Outgoing payments send packets as part of executing the payment.
 
 ## Interledger connector
 

packages/documentation/src/content/docs/integration/playground/overview.mdx

@@ -331,7 +331,7 @@ The sequence of steps outlined below corresponds to the interactions depicted in
 
 :::note
 
-You have to go through an interaction flow by selecting the `redirect` link in the grant request's response. More information about the interaction flow can be found <LinkOut href ='https://openpayments.dev/introduction/grants/'>here</LinkOut>.
+You have to go through an interaction flow by selecting the `redirect` link in the grant request's response. More information about the interaction flow can be found <LinkOut href ='https://openpayments.dev/identity/grants/'>here</LinkOut>.
 :::
 
 8.  Continues the grant request

packages/documentation/src/content/docs/integration/requirements/open-payments/idp.mdx

@@ -24,7 +24,7 @@ We provide Ory Kratos, a cloud-based user management system, for the identity an
 
 In Open Payments, grants indicate a resource owner, such as an account holder, has given a piece of software, such as a mobile app, permission (consent) to act on their behalf.
 
-Rafiki's implementation of an Open Payments authorization server requires that consent is collected via an interactive grant before an <LinkOut href="https://openpayments.dev/introduction/op-concepts/#outgoing-payment">outgoing payment</LinkOut> request is issued. A grant is interactive when explicit interaction by a resource owner (for example, the software's end user) is required to approve or deny the grant. Tapping an _Approve_ button to authorize a payment is an example of an explicit interaction.
+Rafiki's implementation of an Open Payments authorization server requires that consent is collected via an interactive grant before an <LinkOut href="https://openpayments.dev/concepts/resources/#outgoing-payment">outgoing payment</LinkOut> request is issued. A grant is interactive when explicit interaction by a resource owner (for example, the software's end user) is required to approve or deny the grant. Tapping an _Approve_ button to authorize a payment is an example of an explicit interaction.
 
 Interactive grants can be optional for incoming payments and quotes; however, they're enabled by default in Rafiki (the `LIST_ALL_ACCESS_INTERACTION` environment variable is `true`). When a grant request includes a `list-all` action for incoming payments and quotes, the request requires interaction. The `list-all` action is used when the client asks to list resources that it did not create.
 
@@ -33,7 +33,7 @@ If `LIST_ALL_ACCESS_INTERACTION` is `false`, you can still force interactive gra
 - `QUOTE_INTERACTION`
 - `INCOMING_PAYMENT_INTERACTION`
 
-See the <LinkOut href="https://openpayments.dev/introduction/grants/">Open Payments documentation</LinkOut> for more information on grant negotiation and authorization.
+See the <LinkOut href="https://openpayments.dev/identity/grants/">Open Payments documentation</LinkOut> for more information on grant negotiation and authorization.
 
 ## Authorization servers
 

packages/documentation/src/content/docs/integration/requirements/open-payments/wallet-keys.mdx

@@ -8,7 +8,7 @@ import { Tabs, TabItem } from '@astrojs/starlight/components'
 
 Creating a public-private key pair for each wallet address is not required when integrating with Rafiki.
 
-You only need to create key pairs for wallet addresses if you want to allow your account holders to use/be Open Payments clients under their wallet addresses. For more information, review the Open Payments documentation about <LinkOut href="https://openpayments.dev/resources/glossary/#client">clients</LinkOut> and <LinkOut href="https://openpayments.dev/introduction/client-keys/">client keys</LinkOut>.
+You only need to create key pairs for wallet addresses if you want to allow your account holders to use/be Open Payments clients under their wallet addresses. For more information, review the Open Payments documentation about <LinkOut href="https://openpayments.dev/resources/glossary/#client">clients</LinkOut> and <LinkOut href="https://openpayments.dev/identity/client-keys/">client keys</LinkOut>.
 
 ## Create a wallet address key pair
 

packages/documentation/src/content/docs/overview/concepts/open-payments.mdx

@@ -6,7 +6,7 @@ tableOfContents:
 
 import { LinkOut } from '@interledger/docs-design-system'
 
-Rafiki follows the <LinkOut href='https://openpayments.dev'>Open Payments</LinkOut> standard to enable third-party clients to securely retrieve account information and initiate payments from your customers’ accounts with their consent. The standard describes a uniform way to create and manage grants and resources for <LinkOut href='https://openpayments.dev/introduction/op-concepts/#resource-types'>incoming payments, quotes, and outgoing payments</LinkOut>.
+Rafiki follows the <LinkOut href='https://openpayments.dev'>Open Payments</LinkOut> standard to enable third-party clients to securely retrieve account information and initiate payments from your customers’ accounts with their consent. The standard describes a uniform way to create and manage grants and resources for <LinkOut href='https://openpayments.dev/concepts/resources/#resource-types'>incoming payments, quotes, and outgoing payments</LinkOut>.
 
 ### Example use case - retrieve account information
 
@@ -16,16 +16,16 @@ Some of your customers use a third-party application that allows them to create
 
 We strongly encourage you to familiarize yourself with the Open Payments standard. Extensive documentation is available on the <LinkOut href="https://openpayments.dev">Open Payments</LinkOut> website. We recommend you start by reviewing all the pages within the _Intro to Open Payments_ section. Here are a few links to get you started.
 
-- <LinkOut href='https://openpayments.dev/introduction/op-concepts/'>
-    Open Payments concepts
+- <LinkOut href='https://openpayments.dev/overview/getting-started/'>
+    Getting started with Open Payments
   </LinkOut>
-- <LinkOut href='https://openpayments.dev/introduction/client-keys/'>
+- <LinkOut href='https://openpayments.dev/identity/client-keys/'>
     Client keys
   </LinkOut>
-- <LinkOut href='https://openpayments.dev/introduction/http-signatures/'>
+- <LinkOut href='https://openpayments.dev/identity/http-signatures/'>
     HTTP message signatures
   </LinkOut>
-- <LinkOut href='https://openpayments.dev/introduction/grants/'>
+- <LinkOut href='https://openpayments.dev/identity/grants/'>
     Grant negotiation and authorization
   </LinkOut>
 
@@ -35,4 +35,4 @@ Rafiki’s [`backend`](/integration/deployment/services/backend-service) service
 
 ## Rafiki's auth service
 
-Rafiki’s [`auth`](/integration/deployment/services/auth-service) service is a reference implementation of an opinionated Open Payments authorization server. The authorization server is responsible for delegating authorization (via grants) to clients to use the Open Payments APIs, resolving <LinkOut href="https://openpayments.dev/introduction/client-keys/">clients’ public keys</LinkOut> to authenticate and authorize incoming requests, and creating payments and quotes on the backend. Open Payments leverages the Grant Negotiation and Authorization Protocol (GNAP) for delegating authorization. You can learn more about the protocol by reviewing its <LinkOut href="https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-protocol">specification</LinkOut>.
+Rafiki’s [`auth`](/integration/deployment/services/auth-service) service is a reference implementation of an opinionated Open Payments authorization server. The authorization server is responsible for delegating authorization (via grants) to clients to use the Open Payments APIs, resolving <LinkOut href="https://openpayments.dev/identity/client-keys/">clients’ public keys</LinkOut> to authenticate and authorize incoming requests, and creating payments and quotes on the backend. Open Payments leverages the Grant Negotiation and Authorization Protocol (GNAP) for delegating authorization. You can learn more about the protocol by reviewing its <LinkOut href="https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-protocol">specification</LinkOut>.