docs: delete unused doc files (#2732)
This commit is contained in:
Shahed Nasser
GitHub
@@ -1,8 +0,0 @@
|
||||
---
|
||||
templateKey: index-page
|
||||
pageTitle: Medusa docs
|
||||
introTtitle: Documentation
|
||||
introSubtitle: Explore and learn how to use Medusa.
|
||||
introDescriptionTitle: Quickstart
|
||||
introDescriptionSubtitle: Get up and running within 5 minutes, with helpful starters that lay the foundation for growth.
|
||||
---
|
||||
@@ -1,184 +0,0 @@
|
||||
# Cart Service
|
||||
In Medusa a cart is where a customer can add items that they intend to purchase
|
||||
later. The Cart service is responsible for making the operations necessary for
|
||||
handling items in the cart and completing a checkout.
|
||||
|
||||
## Creating carts
|
||||
|
||||
### When to create carts
|
||||
You can create a cart when the user enters the site or when they first add
|
||||
something to the cart.
|
||||
|
||||
If you decide to wait with cart creation until the
|
||||
customer adds something to the cart you have to make sure that the customer sees
|
||||
correct prices/products/etc. for the region they are shopping in. You will also
|
||||
have to ensure that you make a `POST /cart` call before you call `POST
|
||||
/cart/line-items`.
|
||||
|
||||
This can be circumvented by creating the cart as soon as the user enters your
|
||||
site. You will then be able to keep the region data in the cart, which will be
|
||||
ready for any `POST /cart/line-items`. This has the trade-off of creating many
|
||||
unnecessary carts, but is easier to implement.
|
||||
|
||||
## Shopping
|
||||
|
||||
### Adding to the cart
|
||||
The typical user journey is that a customer adds an item to her Cart this
|
||||
usually happens with `POST /cart/line-items`. The endpoint takes a `variant_id`
|
||||
and a `quantity`. The endpoint controller will then retrieve the variant and the
|
||||
product it is associated with, compile a valid `LineItem` and use the
|
||||
CartService function `addLineItem` to create the line item on the cart.
|
||||
|
||||
### Updating line items
|
||||
Updating line items happens with `POST /cart/line-items/[line-id]`. The endpoint
|
||||
takes `quantity` to update the line item's quantity. A quantity of 0 results in
|
||||
a removal of the line item. The endpoint controller uses `updateLineItem` to
|
||||
update the line item.
|
||||
|
||||
### Removing line items
|
||||
Deleting line items happens with `DELETE /cart/line-items/[line-id]`. Endpoint
|
||||
removes the line item with the given line id by calling `removeLineItem`.
|
||||
|
||||
:::note Custom add to cart
|
||||
|
||||
It is possible to make custom endpoints to add to cart. For example if you are
|
||||
creating a gift card plugin you may want to create a custom endpoint that
|
||||
accepts values like `amount` which can be set by the customer. As long as the
|
||||
controller compiles a valid `LineItem` it can safely call `addLineItem`
|
||||
|
||||
:::
|
||||
|
||||
## Checking out
|
||||
|
||||
### Initializing the checkout
|
||||
When the customer is ready to check out they will reach your checkout page. At
|
||||
this point you want to display which payment and shipping options are offered.
|
||||
`POST /cart/payment-sessions` and `POST /cart/fulfillment-sessions` will
|
||||
initialize payment sessions and shipping methods offered by fulfillment
|
||||
providers. The payment sessions will typically have to be updated if any further
|
||||
changes to the cart total happens (shipping fee, promo codes, user exits
|
||||
checkout and adds more items to cart and returns to checkout). Medusa will make
|
||||
sure to update any payment sessions that have already been initialized.
|
||||
|
||||
In cases where shipping rates can vary based on order size, shipping address
|
||||
(with higher granularity than region) makes sense to call `POST
|
||||
/cart/fulfillment-providers` multiple times, e.g. if the customer updates their
|
||||
shipping address and new shipping rates have to be calculated. On each call the
|
||||
endpoint will make sure to only return relevant shipping methods.
|
||||
|
||||
Note that `POST /cart/payment-providers` should not be used to fetch available
|
||||
payment providers, only to initialize payment sessions. If you want to display
|
||||
the available payment providers to the customer you can find an array of these
|
||||
in `region.payment_providers`.
|
||||
|
||||
### Getting customer data
|
||||
To complete a purchase the customer has to fill in her details. The endpoints to
|
||||
do this are `POST /cart/email`, `POST /cart/shipping-address` and `POST /cart/
|
||||
billing-address`. The endpoint controllers use the corresponding Cart service
|
||||
methods (`updateEmail`, `updateShippingAddress`, `updateBillingAddress`) to
|
||||
store the customer information in the cart.
|
||||
|
||||
### Handling payments and completing orders
|
||||
Authorization of payments happen with the payment provider. As such the typical
|
||||
payment flow will be:
|
||||
|
||||
1. the customer enters payment details
|
||||
2. details are sent to the payment provider
|
||||
3. the payment provider authorizes the payment
|
||||
4. the payment method is store in the cart
|
||||
5. the order is processed.
|
||||
|
||||
Steps 4. and 5. are handled with one API call in Medusa. Once the payment is
|
||||
authorized you call `POST /order`. The endpoint takes `cart_id` and
|
||||
`payment_provider_id` as data. The controller will call the Cart service
|
||||
function `setPaymentMethod` which will fetch the cart, search the
|
||||
`payment_sessions` array for the payment associated with `payment_provider` and
|
||||
check that the payment session is authorized. When the authorization is verified
|
||||
the payment method is set and the controller can safely call the Order service
|
||||
function `create`.
|
||||
|
||||
|
||||
### How do payment sessions work?
|
||||
|
||||
When the customer first enters the checkout page you should initialize payment
|
||||
sessions for each of the possible payment providers. This is done with a single
|
||||
call to `POST /cart/payment-sessions`. Calls to `POST /cart/payment-sessions`
|
||||
will either create payment sessions for each payment provider or if the payment
|
||||
sessions have already been initialized ensure that the sessions are up to date (
|
||||
i.e. that the cart amount corresponds to the payment sessions' amounts). When
|
||||
the customer reaches the payment part of the checkout (or alternatively when she
|
||||
decides to use one of the payment providers as a checkout provider) the payment
|
||||
method will be saved once authorized.
|
||||
|
||||
### How do fulfillment sessions work?
|
||||
|
||||
When the customer first enters the checkout page, fulfillment sessions should be
|
||||
initialized. The fulfillment session is responsible for fetching shipping
|
||||
options with a fulfillment provider. E.g. your store has an integration with
|
||||
your 3PL as a fulfillment provider. The 3PL has 4 shipping options: standard,
|
||||
express and fragile shipping as well as a parcel shop service where orders are
|
||||
delivered to a local store.
|
||||
|
||||
The store operator will have set up which shipping options are available in the
|
||||
customer's region. I.e. the store operator may have created a shipping option
|
||||
called Free Shipping, which uses the "Standard Shipping" method from the 3PL
|
||||
integration, and which is free when the order value is above 100 USD. The store
|
||||
operator may have also created an Express Shipping option which uses the
|
||||
"Express Shipping" method from the 3PL integration and which costs 20 USD.
|
||||
The store operator has also created a Fragile Shipping option which uses the
|
||||
"Fragile Shipping" method from the 3PL integration and which has variable
|
||||
pricing depending on the size of the shipment. The variable pricing is
|
||||
calculated by the integration depending on cart. Finally, the store operator has
|
||||
defined a parcel shop option, which uses the 3PL's parcel shop shipping method.
|
||||
The customer needs to provide the ID of the local store that she wants her order
|
||||
delivered to and the shipping method therefore takes some additional input to be
|
||||
a valid shipping method for an order.
|
||||
|
||||
When the customer enters the checkout page the `POST /cart/shipping-options`
|
||||
call will fetch each of the shipping options that the store operator has set up.
|
||||
Extending the above example, an array of shipping options would be stored in the
|
||||
cart in the format:
|
||||
|
||||
```
|
||||
[
|
||||
{
|
||||
_id: [some-id],
|
||||
provider_id: "3pl_integration",
|
||||
name: "Free Shipping",
|
||||
price: 0,
|
||||
data: {
|
||||
// This will contain data specific to the shipping method, i.e. the
|
||||
// id that the 3PL needs in order to process the order with this shipping
|
||||
// method
|
||||
}
|
||||
},
|
||||
{
|
||||
_id: [some-id],
|
||||
provider_id: "3pl_integration",
|
||||
name: "Express Shipping",
|
||||
price: 20,
|
||||
data: {
|
||||
// This will contain data specific to the shipping method, i.e. the
|
||||
// id that the 3PL needs in order to process the order with this shipping
|
||||
// method
|
||||
}
|
||||
},
|
||||
{
|
||||
_id: [some-id],
|
||||
provider_id: "3pl_integration",
|
||||
name: "Fragile Shipping",
|
||||
price: 120, // Calculated from the cart
|
||||
data: {
|
||||
// This will contain data specific to the shipping method, i.e. the
|
||||
// id that the 3PL needs in order to process the order with this shipping
|
||||
// method
|
||||
}
|
||||
},
|
||||
...
|
||||
]
|
||||
```
|
||||
|
||||
If the customer changes her cart, all shipping options will be recalculated. For
|
||||
example, if the customer removes something from the cart so that they no longer
|
||||
qualify for free shipping, the free shipping method will be removed at the same
|
||||
time the fragile shipping method's price will be updated.
|
||||
@@ -1,31 +0,0 @@
|
||||
## Returns
|
||||
|
||||
Returns refer to the situation when a merchant takes back previously purchased items from a customer. A return will usually result in a refund to the customer, with an amount corresponding to the amount received from the customer at the time of purchase.
|
||||
|
||||
A usual return flow follows the steps below:
|
||||
|
||||
1. The customer requests a return - noting the items that they will be sending back.
|
||||
2. The merchant provides the customer with a return label, that will be used on the package that is being sent back.
|
||||
3. The merchant receives the package at their warehouse, and registers the return as being received.
|
||||
4. The merchant refunds the money to the customer, taking any potential return shipping requests into account.
|
||||
|
||||
A different flow that is less common follows the steps:
|
||||
|
||||
1. The customer arranges a shipment themselves.
|
||||
2. The merchant receives the package at their warehouse, and registers the return as being received.
|
||||
3. The merchant refunds the money to the customer, taking any potential return shipping requests into account.
|
||||
|
||||
In Medusa Admin return shipping options are created in the same way that outgoing shipping options are created. Each return shipping option is associated with a region giving you the flexibility to price returns differently depending on the region the order has been placed in. Returns are not required to have shipping methods as it may be the case that return is arranged independently of a fulfillment provider.
|
||||
|
||||
To create a return in Medusa Admin the store operator finds the original order and clicks "Create Return", the store operator then selects the items to be returned along with a shipping option, once the return is created the fulfillment provider takes care of providing the necessary documentation for the return; this can also be viewed in Medusa Admin.
|
||||
|
||||
## Swaps
|
||||
|
||||
A swap can be used in cases where a customer wishes to exchange previously purchased items for different items. Usually this occurs if the customer wants to change the size or color of an item. In Medusa a swap can be initiated to handle the administrative tasks around swaps i.e. requesting a return, taking a payment from the customer for any shipping expenses and fulfilling the new items.
|
||||
|
||||
When a swap is created in Medusa Admin a return request will be initiated immediately generating return labels with the chosen fulfillment provider, furthermore a cart will be created and a payment link generated which can be sent to the customer to authorize a payment. When the return is received the swap can be marked as received and usually this will be where the new goods are to be sent out. The new goods are sent with the shipping method chosen by the customer in the payment process.
|
||||
|
||||
Limitations:
|
||||
- At the moment only swaps that require a payment are supported i.e. swaps that would result in a refund to the customer are not possible.
|
||||
- The customer must have paid for their swap before the items can be returned.
|
||||
|
||||
@@ -1,16 +0,0 @@
|
||||
# ShippingOptionService
|
||||
|
||||
In Medusa, ShippingOptions represent ways that the customer can have their order shipped. Shipping options are defined by the store operator and are linked to a fulfillment provider. When the customer places their order the fulfillment provider plugin will be notified.
|
||||
|
||||
Shipping Options can have either flat rate prices or calculated prices. As the names suggest a flat rate price is a fixed amount, e.g. for Free Shipping, while calculated rates are prices that are calculated by the fulfillment provider.
|
||||
|
||||
## Creating ShippingOptions
|
||||
|
||||
Shipping options are created with POST calls to `/admin/shipping-options`. You can define requirements that the cart should meet in order to allow the shipping option to be applied to it. Furthermore, you should define what Region the shipping option is available in.
|
||||
|
||||
## Using Shipping Options
|
||||
|
||||
Your fulfillment provider may need additional data in order to validate the shipping option for use. For example, the store operator could make a shipping option called "ShopPickup" which is fulfilled by your warehouse and shipped with CarrierX.
|
||||
|
||||
CarrierX sends the order to the customer's local store where the customer can pick up their order. In this case fulfillment provider needs some additional data about which store CarrierX is shipping to. The additional data should be provided in the data field when calling POST `/store/carts/:id/shipping-method`.
|
||||
|
||||
@@ -1,9 +0,0 @@
|
||||
# ShippingProfileService
|
||||
|
||||
In Medusa, a Shipping Profile represents a group of products and shipping options that can fulfill said products. For example, a store may have to product types "Shirts" and "Shorts" which are produced in Italy and UK respectively. In this case the store operator would create two shipping profiles, one for Shirts and one for Shorts, and add the products correspondingly. The store operator can now decide which shipping options can fulfill the products by adding shipping options to each of the profiles.
|
||||
|
||||
Products and Shipping Options can only belong to one shipping profile at a time.
|
||||
|
||||
|
||||
## Using Shipping Profiles
|
||||
The shipping profiles are used to fetch the correct shipping options for a cart. When GET `/store/shipping-options` is called the ShippingProfileService is asked to find all shipping options that can fulfill the cart's products.
|
||||
Reference in New Issue
Block a user