Rebase

docs/developer/app-store/apps/adyen/architecture.mdx

@@ -16,7 +16,7 @@ The Adyen App implements the following [Saleor sync webhooks related to transact
 
 Furthermore, it's also prepared to handle [async Adyen webhooks](https://docs.adyen.com/development-resources/webhooks).
 
-The Adyen App follows the flow described in detail in the [Saleor Payment App documentation](developer/payments.mdx#payment-app).
+The Adyen App follows the flow described in detail in the [Saleor Payment App documentation](developer/payments/overview.mdx#payment-app).
 
 ## Limitations
 

docs/developer/checkout/finalizing.mdx

@@ -10,7 +10,7 @@ Saleor expects to receive a result of the payment transaction processed by the S
 There are two ways to process payments with the Saleor app:
 
 - Using Payment Apps (recommended): The communication between the storefront and the payment app goes through
-  Saleor. Based on the responses from the payment provider, Saleor creates or updates transactions with the [proper statuses and balances automatically](developer/payments.mdx#recalculations-of-transaction-amounts).
+  Saleor. Based on the responses from the payment provider, Saleor creates or updates transactions with the [proper statuses and balances automatically](developer/payments/overview.mdx/lifecycle.mdx#recalculations-of-amounts).
   The API is public and can be accessed by the storefront directly.
 - Using a custom app: Storefront communicated with your App directly. The app handles the payment process and must update balances and statuses in Saleor. Moreover, it's also responsible for creating an order by
   using the `orderCreateFromCheckout` API. The API is protected and requires an app token.
@@ -70,7 +70,7 @@ sequenceDiagram
 
 #### Processing a payment
 
-All details related to processing and managing payments can be found [here](developer/payments.mdx#processing-payments-with-the-payment-app)
+All details related to processing and managing payments can be found [here](developer/payments/overview.mdx#processing-payments-with-the-payment-app)
 
 :::note
 When the checkout is fully paid, the webhook [CHECKOUT_FULLY_PAID](api-reference/webhooks/enums/webhook-event-type-async-enum.mdx#webhookeventtypeasyncenumcheckout_fully_paid) will be triggered.
@@ -247,12 +247,12 @@ As a result, we get an order object:
 #### Managing payments
 
 Saleor uses transaction flow to manage the payments attached to the checkout by Saleor apps.
-You can find more details about it [here](developer/payments.mdx#processing-payments-with-the-payment-app).
+You can find more details about it [here](developer/payments/overview.mdx#processing-payments-with-the-payment-app).
 
 ## Finalizing checkout with Saleor's payment gateways
 
 :::caution
-We are in the process of deprecating payment plugins (payment gateways) in favor of [Payment Apps](developer/payments.mdx). If you plan on building a new integration with Saleor, we recommend using Payment Apps instead.
+We are in the process of deprecating payment plugins (payment gateways) in favor of [Payment Apps](developer/payments/overview.mdx). If you plan on building a new integration with Saleor, we recommend using Payment Apps instead.
 :::
 
 The payment flow uses the Saleor's payment gateway or payment synchronous webhooks to process a payment.

docs/developer/checkout/overview.mdx

@@ -74,7 +74,7 @@ The resulting [`Checkout`](api-reference/checkout/objects/checkout.mdx) object c
 - `id`: a unique checkout ID.
 - `totalPrice`: the total price of the checkout lines and shipping costs.
 - `isShippingRequired`: denotes whether shipping is required for this checkout.
-- `availablePaymentGateways`: a list of [payment gateways](developer/payments.mdx) that are currently configured on your Saleor server and can be used to pay for the checkout. Only gateways that are enabled for a given channel and support the checkout currency are returned. For each gateway, the API returns an ID, a name, and a config object, which for some gateways may return additional information required to initialize or process the payment on the front-end.
+- `availablePaymentGateways`: a list of [payment gateways](developer/payments/overview.mdx) that are currently configured on your Saleor server and can be used to pay for the checkout. Only gateways that are enabled for a given channel and support the checkout currency are returned. For each gateway, the API returns an ID, a name, and a config object, which for some gateways may return additional information required to initialize or process the payment on the front-end.
 - `shippingMethods`: a list of all shipping methods for this checkout. If the items in the cart require shipment.
 - `availableCollectionPoints`: a list of available places for self-pickup. It is calculated based on the given country and available Stocks (for Warehouses which `clickAndCollectOption` field is not set to `DISABLED`).
 

docs/developer/community/faq.mdx

@@ -156,6 +156,6 @@ Please, note that you need `MANAGE_ORDERS` permission to perform this action.
 
 ## How do I test Transactions without a real payment gateway?
 
-Please refer to the [Payments guide](developer/payments.mdx) on how to use the API.
+Please refer to the [Payments guide](developer/payments/overview.mdx) on how to use the API.
 
-You can also check the [community resouces](developer/payments.mdx#community-resources) for dummy payment app that can mimick payment gateway responses.
+You can also check the [community resouces](developer/payments/overview.mdx#community-resources) for dummy payment app that can mimick payment gateway responses.

docs/developer/extending/webhooks/synchronous-events/stored-payment-method.mdx

@@ -132,7 +132,7 @@ This feature was introduced in **Saleor 3.16**.
 :::
 
 A synchronous webhook [STORED_PAYMENT_METHOD_DELETE_REQUESTED](api-reference/webhooks/enums/webhook-event-type-sync-enum.mdx#webhookeventtypesyncenumstored_payment_method_delete_requested) is called when the user requests the deletion of the stored payment method. User can request the deletion of the stored payment method by triggering the mutation [storedPaymentMethodRequestDelete](api-reference/payments/mutations/stored-payment-method-request-delete.mdx).
-More details about the flow can be found [here](developer/payments.mdx#requesting-deletion-of-stored-payment-method).
+More details about the flow can be found [here](developer/payments/overview.mdx#requesting-deletion-of-stored-payment-method).
 
 ### Request
 

docs/developer/extending/webhooks/synchronous-events/transaction.mdx

@@ -455,7 +455,7 @@ This feature was introduced in **Saleor 3.13**.
 :::
 
 The synchronous [PAYMENT_GATEWAY_INITIALIZE_SESSION](api-reference/webhooks/enums/webhook-event-type-sync-enum.mdx#webhookeventtypesyncenumpayment_gateway_initialize_session)
-webhook is called when a customer requests payment gateway initialization by calling the [paymentGatewayInitialize](developer/payments.mdx#initialize-payment-gateway) mutation. The webhook contains details about the object (`Order`/`Checkout`)
+webhook is called when a customer requests payment gateway initialization by calling the [paymentGatewayInitialize](developer/payments/overview.mdx#initialize-payment-gateway) mutation. The webhook contains details about the object (`Order`/`Checkout`)
 for which the payment gateway initialization was requested, the requested amount, and the `data` received from the frontend.
 As a response, the webhook expects the `data` field with all initialization details that will be passed to the storefront.
 
@@ -514,7 +514,7 @@ The example below shows the pre-defined payload that will be used in the case wh
 
 ### Response
 
-The app needs to return the `data` field. The `data` received from the webhook will be returned as a [paymentGatewayInitialize](developer/payments.mdx#initialize-payment-gateway) mutation response.
+The app needs to return the `data` field. The `data` received from the webhook will be returned as a [paymentGatewayInitialize](developer/payments/overview.mdx#initialize-payment-gateway) mutation response.
 
 ```json
 {
@@ -534,7 +534,7 @@ This feature was introduced in **Saleor 3.13**.
 :::
 
 The synchronous [TRANSACTION_INITIALIZE_SESSION](api-reference/webhooks/enums/webhook-event-type-sync-enum.mdx#webhookeventtypesyncenumtransaction_initialize_session) webhook
-is called when a customer begins processing a payment by calling the [transactionInitialize](developer/payments.mdx#initialize-transaction)
+is called when a customer begins processing a payment by calling the [transactionInitialize](developer/payments/overview.mdx#initialize-transaction)
 mutation. The webhook contains details about the object (`Order`/`Checkout`) related to this action, the `transactionItem` object, details related to the
 requested action, and the `data` passed in the mutation input. Saleor expects the response to be in the proper format. Based on the response, the `transactionItem`'s amount can be marked as fully covered
 or marked as a transaction that requires additional actions from the customer, such as processing 3D secure action.
@@ -653,8 +653,8 @@ This feature was introduced in **Saleor 3.13**.
 
 The [TRANSACTION_PROCESS_SESSION](api-reference/webhooks/enums/webhook-event-type-sync-enum.mdx#webhookeventtypesyncenumtransaction_process_session) webhook is called synchronously when
 a customer needs to process additional actions received as a response from either
-the [transactionInitialize](developer/payments.mdx#initialize-transaction) or [transactionProcess](/developer/payments.mdx#process-transaction) mutations. This webhook is triggered when the customer calls the
-[transactionProcess](/developer/payments.mdx#process-transaction) mutation.
+the [transactionInitialize](developer/payments/overview.mdx#initialize-transaction) or [transactionProcess](/developer/payments/overview.mdx#process-transaction) mutations. This webhook is triggered when the customer calls the
+[transactionProcess](/developer/payments/overview.mdx#process-transaction) mutation.
 It contains details about the `Order` or `Checkout` object related to this action, the `transactionItem` object, details related to the requested action, and the `data` passed in the mutation input.
 Saleor expects the response to be in the proper format. Based on the response, the amount of the `transactionItem` can be marked as fully covered or marked as a transaction
 that requires additional actions from the customer, such as processing a 3D secure action.