fix: fix broken Open payments docs link

src/content/blog/2024-07-30-open-payments-cinderella-story.mdx

@@ -20,7 +20,7 @@ If you’ve ever signed into a website with your Google account, Apple ID, or pe
 
 At a certain point in [Rafiki’s](https://rafiki.dev/) development it became necessary to implement a standard that described how third parties could initiate payments on behalf of someone else. This standard came to be known as Open Payments, which not only would have to provide a framework to describe those payments, but also incorporate an access delegation method for those third parties to use. Having such a well-established access delegation method like OAuth 2.0 made it seem like a clear choice as an authorization method for this standard.
 
-However, as [Open Payment’s](https://openpayments.dev/introduction/overview/) methods for describing and managing payments became fleshed out, the shortcomings of OAuth 2.0 for that use case revealed themselves. To understand what they are, let’s first go over the features of OAuth 2.0 that helped propel it into mainstream popularity.
+However, as [Open Payment’s](https://openpayments.dev/overview/getting-started/) methods for describing and managing payments became fleshed out, the shortcomings of OAuth 2.0 for that use case revealed themselves. To understand what they are, let’s first go over the features of OAuth 2.0 that helped propel it into mainstream popularity.
 
 As simple of a process as it is for a user, access delegation through OAuth 2.0 is achieved through a lot of moving parts by different parties. These roles are as follows:
 
@@ -180,4 +180,4 @@ For reference, we have a more tame sequence diagram with GNAP. It’s closer to
 
 With this in mind, it’s clear that GNAP is best suited for sending payments via Open Payments. Though the spec is not officially final, progress is steady and the future looks promising - the specifications are well on their way to becoming a proper RFC. [The core protocol](https://datatracker.ietf.org/doc/draft-ietf-gnap-core-protocol/) was recently approved by the IESG and has entered the IESG editor’s queue. [The specification for resource servers](https://datatracker.ietf.org/doc/draft-ietf-gnap-resource-servers/) is also on the cusp of being submitted to the IESG for publication.
 
-For more information on Open Payments as a whole, consider perusing the [documentation](https://openpayments.dev/introduction/overview/).
+For more information on Open Payments as a whole, consider perusing the [documentation](https://openpayments.dev/overview/getting-started/).

src/content/blog/2024-08-13-el-universo-interledger.mdx

@@ -149,7 +149,7 @@ Content-Type: application/spsp4+json
 
 Entre ellos se encuentran la `destination_account`, que es la dirección de ILP del destinatario, y un `shared_secret` para cifrar los paquetes STREAM. El protocolo SPSP garantiza una configuración de pagos segura y sencilla para entidades o personas con acceso directo a ILP, es decir, aquellas que pueden crear, enviar y recibir paquetes ILP sin intervención de terceros.
 
-Por su parte, [Open Payments](https://openpayments.dev/introduction/overview/) constituye un estándar de API destinado a entidades proveedoras de servicios de cuentas, que permite a terceros acceder de forma segura a cuentas digitales tanto para consultar información como para iniciar pagos. Mediante un marco sólido para la autorización y ejecución de pagos digitales, Open Payments admite escenarios complejos, como el comercio electrónico o los pagos recurrentes. Para lograr un control de acceso granular y una autorización segura, emplea el [Protocolo de Negociación y Autorización de Concesiones (GNAP)](https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-protocol-20).
+Por su parte, [Open Payments](https://openpayments.dev/overview/getting-started/) constituye un estándar de API destinado a entidades proveedoras de servicios de cuentas, que permite a terceros acceder de forma segura a cuentas digitales tanto para consultar información como para iniciar pagos. Mediante un marco sólido para la autorización y ejecución de pagos digitales, Open Payments admite escenarios complejos, como el comercio electrónico o los pagos recurrentes. Para lograr un control de acceso granular y una autorización segura, emplea el [Protocolo de Negociación y Autorización de Concesiones (GNAP)](https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-protocol-20).
 
 Si desea profundizar en Open Payments, puede consultar la [fantástica publicación de blog de Sarah](https://interledger.org/developers/blog/simple-open-payments-guide/). Si desea obtener una visión general más detallada de GNAP y de por qué lo utilizamos con Open Payments, consulte la [Historia de Cenicienta de Nathan sobre cómo encontrar un método de autorización adecuado](https://interledger.org/developers/blog/open-payments-cinderella-story/).
 

src/content/blog/2024-08-13-interledger-universe.mdx

@@ -148,7 +148,7 @@ Content-Type: application/spsp4+json
 
 These include the `destination_account`, which is the ILP address of the recipient, and a `shared_secret` for encrypting STREAM packets. SPSP ensures a secure and straightforward payment setup for entities or individuals with direct ILP access, meaning entities or individuals that are able to create, send, and receive ILP packets directly without the help of another entity.
 
-[Open Payments](https://openpayments.dev/introduction/overview/) is an API standard for account servicing entities, allowing third parties to securely access digital accounts for viewing account information and initiating payments. Open Payments supports complex payment scenarios, such as e-commerce or recurring payments, by providing a robust framework for authorizing and initiating digital payments. It employs the [Grant Negotiation and Authorization Protocol (GNAP)](https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-protocol-20) for fine-grained access control and secure authorization.
+[Open Payments](https://openpayments.dev/overview/getting-started/) is an API standard for account servicing entities, allowing third parties to securely access digital accounts for viewing account information and initiating payments. Open Payments supports complex payment scenarios, such as e-commerce or recurring payments, by providing a robust framework for authorizing and initiating digital payments. It employs the [Grant Negotiation and Authorization Protocol (GNAP)](https://datatracker.ietf.org/doc/html/draft-ietf-gnap-core-protocol-20) for fine-grained access control and secure authorization.
 
 For an in-depth introduction to Open Payments, check out [Sarah’s fantastic blog post](https://interledger.org/developers/blog/simple-open-payments-guide/). If you would like a more high level overview of GNAP and why we are using it with Open Payments, check out [Nathan's Cinderella Story of Finding a Fitting Authorization Method](https://interledger.org/developers/blog/open-payments-cinderella-story/).
 

src/content/blog/2024-09-23-rafiki-code-architecture.mdx

@@ -26,7 +26,7 @@ So, what makes Rafiki tick? What do we see when we venture beyond _what_ Rafiki
 
 This article assumes the reader has high-level knowledge of the following concepts:
 
-- [Open Payments](https://openpayments.dev/introduction/overview/)
+- [Open Payments](https://openpayments.dev/overview/getting-started/)
 - [Interledger](https://interledger.org/developers/get-started/#how-does-interledger-work)
 
 This article also assumes that its readers already have high-level knowledge of [Rafiki](https://rafiki.dev/overview/overview/) itself, and that they understand on that level how it accomplishes being an Interledger node and an Open Payments server.

src/content/blog/2025-02-05-ilp-packet-lifecycle.mdx

@@ -22,7 +22,7 @@ Though Rafiki's main purpose is to abstract this, the fresh intrigue around Inte
 
 ### Setting the Terms
 
-Before it starts sending all those ILP packets, a higher-level protocol is needed to set the terms of the payment as Interledger doesn't have any mechanism to negotiate payment terms. Rafiki uses the [Open Payments Standard](https://openpayments.dev/introduction/overview/) to achieve this.
+Before it starts sending all those ILP packets, a higher-level protocol is needed to set the terms of the payment as Interledger doesn't have any mechanism to negotiate payment terms. Rafiki uses the [Open Payments Standard](https://openpayments.dev/overview/getting-started/) to achieve this.
 
 A prospective debitor will use this standard to set payment terms by first creating an _incoming payment_ on the Rafiki instance hosting the receiving wallet address, during which the receiving Rafiki instance will associate an ILP address with the incoming payment and generate a shared secret for it.
 Then it may acquire a _quote_ from the Rafiki instance hosting the sending wallet address, which becomes associated with the incoming payment.

src/content/blog/2025-05-06-introducing-open-payments-php.mdx

@@ -124,7 +124,7 @@ We’re just getting started!
 
 Here’s what’s coming soon for Open Payments PHP:
 
-📚 [Open Payments official documentation](https://openpayments.dev/introduction/overview/) will soon include usage examples (snippets) for the PHP library also.
+📚 [Open Payments official documentation](https://openpayments.dev/overview/getting-started/) will soon include usage examples (snippets) for the PHP library also.
 
 🔥 Example projects — showcasing integration with popular frameworks like Laravel, Symfony Console apps ([Snippets library](https://github.com/interledger/open-payments-php-snippets/)), and WordPress - ecommerce - plugins.