Add checkout page

[Vladyslav-Kuksiuk]

This PR adds checkout page .../checkout?product={product-id}.

Predefined test Paygate product: spine-standard-support.

⚠️Current implementation is facing staging Paygate backend

Page view:

Server Error view (when something is broken in the middle of checkout):

Product not found page (when Paygate is available, but answers 404):

Thank you page (.../checkout-completed)

Ooops page

[dmytro-kashcheiev]

@Vladyslav-Kuksiuk its ok now from the code perspective, but I want to request a few more features from UI-UX:

1. Since VAT ID is a toxic field, I propose to add an in-progress spinner somewhere in the field that shows that we are actually validating it right now and it's not either aprooved / rejected.
2. IF VAT passes verification, highlight the field a little green and even maybe small text like: Provided ID is active and valid.
3. Lets fix the following behavior: When I have already filled everything and then press Continue to payment. If on a new page, I decided I want to double check my address and press the return button. I lose part of the filled data and proceed back.

[MykytaPimonovTD]

@Vladyslav-Kuksiuk General comment. Let’s make the product ID a path variable instead of an argument.

The current issue is that a customer could effectively specify any ID, and our payment system would accept it even if it isn’t the expected Spine product.

If we specify products as path variables—like /checkout/spine-support-50h—this will require us to add a new content file to each product page, where the actual ID will be specified in the frontmetters. And we decide which product pages to display on the website.

I believe this approach has another advantage: logically, we’ll have a separate page for each product, which makes sense for a static site.

@dmytro-kashcheiev what do you think?

[Vladyslav-Kuksiuk]

@Vladyslav-Kuksiuk General comment. Let’s make the product ID a path variable instead of an argument.

The current issue is that a customer could effectively specify any ID, and our payment system would accept it even if it isn’t the expected Spine product.

If we specify products as path variables—like /checkout/spine-support-50h—this will require us to add a new content file to each product page, where the actual ID will be specified in the frontmetters. And we decide which product pages to display on the website.

I believe this approach has another advantage: logically, we’ll have a separate page for each product, which makes sense for a static site.

@dmytro-kashcheiev what do you think?

1. If we don’t have such a product, the server will respond with a 404, so the user won’t be able to specify any product. (When we introduce JxBrowser products, we may use different endpoints.)
2. I’m not sure we always want to represent a new product as a separate page. For example, if a customer wants a custom Spine support pack (this wasn’t part of the previous discussion, but I believe that if demand grows, these support packs will become configurable), creating a separate page for each product would be cumbersome and wouldn’t provide any real benefit.
3. In one of our discussions, we mentioned that we might want to include a company as part of the place-order request. In that case, it may look inconsistent if the product and company are specified differently.

[MykytaPimonovTD]

@Vladyslav-Kuksiuk General comment. Let’s make the product ID a path variable instead of an argument.
The current issue is that a customer could effectively specify any ID, and our payment system would accept it even if it isn’t the expected Spine product.
If we specify products as path variables—like /checkout/spine-support-50h—this will require us to add a new content file to each product page, where the actual ID will be specified in the frontmetters. And we decide which product pages to display on the website.
I believe this approach has another advantage: logically, we’ll have a separate page for each product, which makes sense for a static site.
@dmytro-kashcheiev what do you think?

1. If we don’t have such a product, the server will respond with a 404, so the user won’t be able to specify any product. (When we introduce JxBrowser products, we may use different endpoints.)
2. I’m not sure we always want to represent a new product as a separate page. For example, if a customer wants a custom Spine support pack (this wasn’t part of the previous discussion, but I believe that if demand grows, these support packs will become configurable), creating a separate page for each product would be cumbersome and wouldn’t provide any real benefit.
3. In one of our discussions, we mentioned that we might want to include a company as part of the place-order request. In that case, it may look inconsistent if the product and company are specified differently.

@Vladyslav-Kuksiuk OK. I agree.

[dmytro-kashcheiev]

@Vladyslav-Kuksiuk LGTM from my side.

[MykytaPimonovTD]

@Vladyslav-Kuksiuk LGTM.