docs: fixes in shipping, payment, and other documentations

* added integration * add segment for API reference * updated frontend checkout flow * added paypal documentation * Improve storefront quickstart documents * added documentation for entities * docs: disable running tests for docs * added docs contribution guidelines * Use npm2yarn where missing * added additional steps section * added notification overview * Added guidelines for sidebar labels * added how to create notification provider * fixes * fixes for payment provider * fixes * chore(deps): bump sqlite3 from 5.0.2 to 5.0.3 (#1453) Bumps [sqlite3](https://github.com/TryGhost/node-sqlite3) from 5.0.2 to 5.0.3. - [Release notes](https://github.com/TryGhost/node-sqlite3/releases) - [Changelog](https://github.com/TryGhost/node-sqlite3/blob/master/CHANGELOG.md) - [Commits](https://github.com/TryGhost/node-sqlite3/compare/v5.0.2...v5.0.3) * fix: Issue with cache in CI pipeline * Use npm2yarn where missing * added integration * add segment for API reference * fix double segment * updated frontend checkout flow * added documentation for entities * added docs contribution guidelines * Added guidelines for sidebar labels * added additional steps section * added notification overview * added how to create notification provider * chore: Add issue template for bug reports (#1676) * chore: Add issue template for feature requests (#1679) * fixes * fixes for payment provider * fixes Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Oliver Windall Juhl <59018053+olivermrbl@users.noreply.github.com>
2022-06-17 11:31:05 +03:00
1 parent 2c266302c8
commit 0bfdaab34e
@@ -70,7 +70,7 @@ Following the naming convention of Services, the name of the file should be the

 As mentioned in the overview, Payment Providers should have a static `identifier` property.

-The `PaymentProvider` model has 2 properties: `identifier` and `is_installed`. The value of the `identifier` property in the class will be used when the Payment Provider is created in the database.
+The `PaymentProvider` entity has 2 properties: `identifier` and `is_installed`. The value of the `identifier` property in the class will be used when the Payment Provider is created in the database.

 The value of this property will also be used to reference the Payment Provider throughout the Medusa server. For example, the identifier is used when a [Payment Session in a cart is selected on checkout](https://docs.medusajs.com/api/store/cart/select-a-payment-session).

@@ -1,4 +1,4 @@
-# Architecture Overview
+# Payment Architecture Overview

 In this document, you’ll learn about the payment architecture in Medusa, specifically its 3 main components and the idempotency key.

@@ -16,15 +16,13 @@ An important part in the Payment architecture to understand is the **Idempotency

 ## Payment Provider

-### Overview
-
 A Payment Provider in Medusa is a method to handle payments in selected regions. It is not associated with a cart, customer, or order in particular. It provides the necessary implementation to create Payment Sessions and Payments, as well as authorize and capture payments, among other functionalities.

 Payment Providers can be integrated with third-party services that handle payment operations such as capturing a payment. An example of a Payment Provider is Stripe.

 Payment Providers can also be related to a custom way of handling payment operations. An example of that is cash on delivery (COD) payment methods or Medusa’s [manual payment provider plugin](https://github.com/medusajs/medusa/tree/master/packages/medusa-payment-manual) which provides a minimal implementation of a payment provider and allows store operators to manually handle order payments.

-### How it is Created
+### How Payment Provider is Created

 A Payment Provider is essentially a Medusa [service](../services/create-service.md) with a unique identifier, and it extends the `PaymentService` provided by the `medusa-interfaces` package. It can be created as part of a [plugin](../../../guides/plugins.md), or it can be created just as a service file in your Medusa server.

@@ -40,21 +38,19 @@ It’s important to choose a payment provider in the list of payment providers i

 :::

-### Model Overview
+### PaymentProvider Entity Overview

-The `PaymentProvider` model only has 2 attributes: `is_installed` to indicate if the payment provider is installed and its value is a boolean; and `id` which is the unique identifier that you define in the Payment Provider service.
+The `PaymentProvider` entity only has 2 attributes: `is_installed` to indicate if the payment provider is installed and its value is a boolean; and `id` which is the unique identifier that you define in the Payment Provider service.

 ## Payment Session

-### Overview
-
 Payment Sessions are linked to a customer’s cart. Each Payment Session is associated with a payment provider that is available in the customer cart’s region.

 They hold the status of the payment flow throughout the checkout process which can be used to indicate different statuses such as an authorized payment or payment that requires more actions from the customer.

 After the checkout process is completed and the Payment Session has been authorized successfully, a Payment instance will be created to be associated with the customer’s order and will be used for further actions related to that order.

-### How it is Created
+### How Payment Session is Created

 After the customer adds products to the cart, proceeds with the checkout flow, and reaches the payment method section, Payment Sessions are created for each Payment Provider available in that region. 

@@ -64,15 +60,15 @@ Payment Sessions can hold data that is necessary for the customer to complete th

 Among the Payment Sessions available only one will be selected based on the customer’s payment provider choice. For example, if the customer sees that they can pay with Stripe or PayPal and chooses Stripe, Stripe’s Payment Session will be the selected Payment Session of that cart.

-### Model Overview
+### PaymentSession Entity Overview

-The `PaymentSession` model belongs to a `Cart`. This is the customer‘s cart that was used for checkout which lead to the creation of the Payment Session.
+The `PaymentSession` entity belongs to a `Cart`. This is the customer‘s cart that was used for checkout which lead to the creation of the Payment Session.

 The `PaymentSession` also belongs to a `PaymentProvider`. This is the Payment Provider that was used to create the Payment Session and that controls it for further actions like authorizing the payment.

 The `data` attribute is an object that holds any data required for the Payment Provider to perform payment operations like authorizing or capturing payment. For example, when a Stripe payment session is initialized, the `data` object will hold the payment intent among other data necessary to authorize the payment.

-The `is_selected` attribute in the `PaymentSession` model is a boolean value that indicates whether this Payment Session was selected by the customer to pay for their purchase. Going back to the previous example of having Stripe and PayPal as the available Payment Providers, when the customer chooses Stripe, Stripe’s Payment Session will have `is_selected` set to true whereas PayPal’s Payment Session will have `is_selected` set to false.
+The `is_selected` attribute in the `PaymentSession` entity is a boolean value that indicates whether this Payment Session was selected by the customer to pay for their purchase. Going back to the previous example of having Stripe and PayPal as the available Payment Providers, when the customer chooses Stripe, Stripe’s Payment Session will have `is_selected` set to true whereas PayPal’s Payment Session will have `is_selected` set to false.

 The `status` attributes indicates the current status of the Payment Session. It can be one of the following values:

@@ -86,21 +82,19 @@ These statuses are important in the checkout flow to determine the current step

 ## Payment

-### Overview
-
 A Payment is used to represent the amount authorized for a customer’s purchase. It is associated with the order placed by the customer and will be used after that for all operations related to the order’s payment such as capturing or refunding the payment.

 Payments are generally created using data from the Payment Session and it holds any data that can be necessary to perform later payment operations.

-### How it is Created
+### How Payment is Created

 Once the customer completes their purchase and the payment has been authorized, a Payment instance will be created from the Payment Session. The Payment is associated first with the cart and then with the order once it’s created and placed.

 When the store operator then chooses to capture the order from the Medusa Admin, the Payment is used by the Payment Provider to capture the payment. This is the same case for refunding the amount, canceling the order, or creating a swap.

-### Model Overview
+### Payment Entity Overview

-The `Payment` model belongs to the `Cart` that it was originally created from when the customer’s payment was authorized. It also belongs to an `Order` once it’s placed. Additionally, it belongs to a `PaymentProvider` which is the payment provider that the customer chose on checkout.
+The `Payment` entity belongs to the `Cart` that it was originally created from when the customer’s payment was authorized. It also belongs to an `Order` once it’s placed. Additionally, it belongs to a `PaymentProvider` which is the payment provider that the customer chose on checkout.

 In case a `Swap` is created for an order, `Payment` will be associated with that swap to handle payment operations related to it.