Merge pull request #56 from placetopay-org/feature/rewrite-wip

src/pages/checkout/api/changelog.mdx

@@ -1,15 +1,10 @@
-export const sectionMode = 'none'
 export const description =
   'Conoce el historial de cambios de Checkout API y aprovecha las nuevas funcionalidades.'
 
 # Historial de cambios - Changelog
 
 Este archivo contiene las mejoras y actualizaciones que se hagan en Checkout API.
 
-## Sin desplegar {{ id: 'undeployed' }}
-
-...
-
 ## `2.20.0` 2024-05-02
 
 ### Nuevo:

src/pages/checkout/api/policy.mdx

@@ -1,23 +1,21 @@
 export const description =
-  'Conoce la politica de cambios retrocompatibles en Checkout API.'
+  'Conoce la politica de cambios retrocompatibles en Placetopay API.'
 
 # API Version Policy
 
 En Placetopay contamos con una única versión del api disponible hasta la fecha. Tal que si te vas a conectar o ya estas conectado con nuestro api, estás usando la única versión disponible. {{ className: 'lead' }}
 
 Al tratarse de una única versión de API, todas las funcionalidades nuevas y ajustes se hacen en la misma versión del API y pretenden ser **retro-compatibles**.
 
-## Cambios Retro-compatibles {{ id: 'backwards-compatible-changes' }}
+En Placetopay consideramos los siguientes cambios retro-compatibles
 
-En Placetopay consideramos los siguientes cambios retro-compatibles:
-
-### Agregar nuevos recursos y endpoints.
+## Agregar nuevos recursos y endpoints. {{ id: "new-resources"}}
 
 Cuando se agrega una nueva funcionalidad, es muy probable que venga acompañada de un nuevo endpoint y/o recurso.
 
 **Ejemplo:** Si se hiciera el lanzamiento de un nuevo API para obtener usuarios, la funcionalidad llevaría a un nuevo recurso `User` y nuevo endpoint `api.com/users`.   
 
-### Agregar nuevos parámetros opcionales a las solicitudes de API existentes
+## Agregar nuevos parámetros opcionales a las solicitudes de API existentes. {{ id: "new-parameters"}}
 
 Debido a la evolución de algunas funcionalidades, es probable que agreguemos nuevos parámetros **opcionales** en las solicitudes que pueden hacer los clientes integradores.
 
@@ -36,7 +34,7 @@ Debido a la evolución de algunas funcionalidades, es probable que agreguemos nu
 
 Este nuevo parámetro será **opcional** y no afectará las integraciones existentes.
 
-### Agregar nuevas propiedades en respuestas de API existentes
+## Agregar nuevas propiedades en respuestas de API existentes. {{ id: "new-properties"}}
 
 Debido a la evolución de algunas funcionalidades, es probable que algunas respuestas del api incluyan nuevas propiedades.
 
@@ -57,7 +55,7 @@ Debido a la evolución de algunas funcionalidades, es probable que algunas respu
 
 Esta nueva propiedad será incluida y no afectará las integraciones existentes.
 
-### Cambiar el orden de propiedades en respuestas de API existentes
+## Cambiar el orden de propiedades en respuestas de API existentes. {{ id: "order-of-properties"}}
 
 Debido a la evolución de algunas funcionalidades, es probable que algunas respuestas del api cambien el orden de sus propiedades.
 
@@ -81,7 +79,7 @@ Debido a la evolución de algunas funcionalidades, es probable que algunas respu
 
 Este cambio no afectará las integraciones existentes.
 
-### Cambiar parámetros requeridos a opcionales en las solicitudes de API existentes
+## Cambiar parámetros requeridos a opcionales en las solicitudes de API existentes. {{ id: "property-rules"}}
 
 Debido a la evolución de algunas funcionalidades, es probable que cambiemos un parámetro existente que es requerido a **opcional** en las solicitudes que pueden hacer los clientes integradores.
 
@@ -102,5 +100,3 @@ Debido a la evolución de algunas funcionalidades, es probable que cambiemos un
 Este cambio no afectará las integraciones existentes.
 
 No se podrá hacer lo contrario, es decir, un parámetro opcional no se podrá volver **requerido**.
-
-

src/pages/checkout/refund.mdx

@@ -9,7 +9,7 @@ Para realizar un reembolso debes conocer la referencia interna de la transacció
 
 ## ¿Cómo realizar un reembolso? {{ id: 'how-to-make-a-refund' }}
 
-Para realizar un reembolso se debe hacer una petición al endpoint [Reembolsar Transacción](/checkout/api/reference/payment#reverse-payment). Existen dos tipos de reembolsos *total* o *parcial*:
+Para realizar un reembolso se debe hacer una petición al endpoint [Reembolsar Transacción](/checkout/api/reference/payment#refund-payment). De acuerdo a la necesidad es posible hacer reembolsos totales y reembolsos parciales.
 
 ### Reembolso total
 

src/pages/en/checkout/api/policy.mdx

@@ -1,23 +1,21 @@
 export const description =
-  'Know the policy of backward compatible changes in Checkout API.'
+  'Know the policy of backward compatible changes in Placetopay API.'
 
 # API Version Policy
 
 At Placetopay we have only one version of the api available to date. So if you are going to connect or are already connected to our api, you are using the only version available. {{ className: 'lead' }}
 
 As it is a single API version, all new features and adjustments are made in the same API version and are intended to be **backward-compatible**.
 
-## Backward Compatible Changes {{ id: 'backwards-compatible-changes' }}
-
 At Placetopay we consider the following changes backward compatible:
 
-### Add new resources and endpoints.
+## Add new resources and endpoints. {{ id: "new-resources"}}
 
 When a new functionality is added, it is very likely that it will be accompanied by a new endpoint and/or resource.
 
 **Example:** If a new API was released to get users, the functionality would lead to a new `User` resource and a new `api.com/users` endpoint.   
 
-### Add new optional parameters to existing API requests
+## Add new optional parameters to existing API requests. {{ id: "new-parameters"}}
 
 Due to the evolution of some functionalities, it is possible that we will add new **optional** parameters in the requests that can be made by integrator clients.
 
@@ -36,7 +34,7 @@ Due to the evolution of some functionalities, it is possible that we will add ne
 
 This new parameter will be **optional** and will not affect existing integrations.
 
-### Add new properties to existing API responses
+## Add new properties to existing API responses {{ id: "new-properties"}}
 
 Due to the evolution of some functionalities, it is possible that some api responses include new properties.
 
@@ -57,7 +55,7 @@ Due to the evolution of some functionalities, it is possible that some api respo
 
 This new property will be included and will not affect existing integrations.
 
-### Change the order of properties in existing API responses
+## Change the order of properties in existing API responses. {{ id: "order-of-properties"}}
 
 Due to the evolution of some functionalities, it is probable that some api responses will change the order of their properties.
 
@@ -81,7 +79,7 @@ Due to the evolution of some functionalities, it is probable that some api respo
 
 This change will not affect existing integrations.
 
-### Change required parameters to optional in existing API requests
+## Change required parameters to optional in existing API requests. {{ id: "property-rules"}}
 
 Due to the evolution of some functionality, we may change an existing parameter that is required to **optional** in requests that can be made by integrator clients.
 

src/pages/en/checkout/refund.mdx

@@ -9,7 +9,7 @@ To process a refund, you need to know the internal reference of the transaction
 
 ## How to make a refund? {{ id: 'how-to-make-a-refund' }}
 
-To process a refund, you need to make a request to the [Refund Transaction](/en/checkout/api/reference/payment#reverse-payment) endpoint. There are two types of refunds: *full* or *partial*:
+To process a refund, you need to make a request to the [Refund Transaction](/en/checkout/api/reference/payment#refund-payment) endpoint. Depending on the need, it is possible to make full refunds and partial refunds. According to the need, it is possible to make full refunds and partial refunds. According to the need, it is possible to make full refunds and partial refunds.
 
 ### Full Refund
 

src/pages/en/gateway/api/policy.mdx

@@ -1,23 +1,21 @@
 export const description =
-  'Know the policy of backward compatible changes in Checkout API.'
+  'Know the policy of backward compatible changes in Placetopay API.'
 
 # API Version Policy
 
 At Placetopay we have only one version of the api available to date. So if you are going to connect or are already connected to our api, you are using the only version available. {{ className: 'lead' }}
 
 As it is a single API version, all new features and adjustments are made in the same API version and are intended to be **backward-compatible**.
 
-## Backward Compatible Changes {{ id: 'backwards-compatible-changes' }}
-
 At Placetopay we consider the following changes backward compatible:
 
-### Add new resources and endpoints.
+## Add new resources and endpoints. {{ id: "new-resources"}}
 
 When a new functionality is added, it is very likely that it will be accompanied by a new endpoint and/or resource.
 
 **Example:** If a new API was released to get users, the functionality would lead to a new `User` resource and a new `api.com/users` endpoint.   
 
-### Add new optional parameters to existing API requests
+## Add new optional parameters to existing API requests. {{ id: "new-parameters"}}
 
 Due to the evolution of some functionalities, it is possible that we will add new **optional** parameters in the requests that can be made by integrator clients.
 
@@ -36,7 +34,7 @@ Due to the evolution of some functionalities, it is possible that we will add ne
 
 This new parameter will be **optional** and will not affect existing integrations.
 
-### Add new properties to existing API responses
+## Add new properties to existing API responses {{ id: "new-properties"}}
 
 Due to the evolution of some functionalities, it is possible that some api responses include new properties.
 
@@ -57,7 +55,7 @@ Due to the evolution of some functionalities, it is possible that some api respo
 
 This new property will be included and will not affect existing integrations.
 
-### Change the order of properties in existing API responses
+## Change the order of properties in existing API responses. {{ id: "order-of-properties"}}
 
 Due to the evolution of some functionalities, it is probable that some api responses will change the order of their properties.
 
@@ -81,7 +79,7 @@ Due to the evolution of some functionalities, it is probable that some api respo
 
 This change will not affect existing integrations.
 
-### Change required parameters to optional in existing API requests
+## Change required parameters to optional in existing API requests. {{ id: "property-rules"}}
 
 Due to the evolution of some functionality, we may change an existing parameter that is required to **optional** in requests that can be made by integrator clients.
 

src/pages/gateway/api/policy.mdx

@@ -1,23 +1,21 @@
 export const description =
-  'Conoce la politica de cambios retrocompatibles en Checkout API.'
+  'Conoce la politica de cambios retrocompatibles en Placetopay API.'
 
 # API Version Policy
 
 En Placetopay contamos con una única versión del api disponible hasta la fecha. Tal que si te vas a conectar o ya estas conectado con nuestro api, estás usando la única versión disponible. {{ className: 'lead' }}
 
 Al tratarse de una única versión de API, todas las funcionalidades nuevas y ajustes se hacen en la misma versión del API y pretenden ser **retro-compatibles**.
 
-## Cambios Retro-compatibles {{ id: 'backwards-compatible-changes' }}
+En Placetopay consideramos los siguientes cambios retro-compatibles
 
-En Placetopay consideramos los siguientes cambios retro-compatibles:
-
-### Agregar nuevos recursos y endpoints.
+## Agregar nuevos recursos y endpoints. {{ id: "new-resources"}}
 
 Cuando se agrega una nueva funcionalidad, es muy probable que venga acompañada de un nuevo endpoint y/o recurso.
 
 **Ejemplo:** Si se hiciera el lanzamiento de un nuevo API para obtener usuarios, la funcionalidad llevaría a un nuevo recurso `User` y nuevo endpoint `api.com/users`.   
 
-### Agregar nuevos parámetros opcionales a las solicitudes de API existentes
+## Agregar nuevos parámetros opcionales a las solicitudes de API existentes. {{ id: "new-parameters"}}
 
 Debido a la evolución de algunas funcionalidades, es probable que agreguemos nuevos parámetros **opcionales** en las solicitudes que pueden hacer los clientes integradores.
 
@@ -36,7 +34,7 @@ Debido a la evolución de algunas funcionalidades, es probable que agreguemos nu
 
 Este nuevo parámetro será **opcional** y no afectará las integraciones existentes.
 
-### Agregar nuevas propiedades en respuestas de API existentes
+## Agregar nuevas propiedades en respuestas de API existentes. {{ id: "new-properties"}}
 
 Debido a la evolución de algunas funcionalidades, es probable que algunas respuestas del api incluyan nuevas propiedades.
 
@@ -57,7 +55,7 @@ Debido a la evolución de algunas funcionalidades, es probable que algunas respu
 
 Esta nueva propiedad será incluida y no afectará las integraciones existentes.
 
-### Cambiar el orden de propiedades en respuestas de API existentes
+## Cambiar el orden de propiedades en respuestas de API existentes. {{ id: "order-of-properties"}}
 
 Debido a la evolución de algunas funcionalidades, es probable que algunas respuestas del api cambien el orden de sus propiedades.
 
@@ -81,7 +79,7 @@ Debido a la evolución de algunas funcionalidades, es probable que algunas respu
 
 Este cambio no afectará las integraciones existentes.
 
-### Cambiar parámetros requeridos a opcionales en las solicitudes de API existentes
+## Cambiar parámetros requeridos a opcionales en las solicitudes de API existentes. {{ id: "property-rules"}}
 
 Debido a la evolución de algunas funcionalidades, es probable que cambiemos un parámetro existente que es requerido a **opcional** en las solicitudes que pueden hacer los clientes integradores.
 
@@ -102,5 +100,3 @@ Debido a la evolución de algunas funcionalidades, es probable que cambiemos un
 Este cambio no afectará las integraciones existentes.
 
 No se podrá hacer lo contrario, es decir, un parámetro opcional no se podrá volver **requerido**.
-
-