Skip to content

Commit

Permalink
Apply suggestions from code review
Browse files Browse the repository at this point in the history
Co-authored-by: albertfolch-redeemeum <102516373+albertfolch-redeemeum@users.noreply.github.com>
  • Loading branch information
levalleux-ludo and albertfolch-redeemeum committed Oct 23, 2023
1 parent 4b2243f commit 2ef2a07
Show file tree
Hide file tree
Showing 5 changed files with 25 additions and 25 deletions.
10 changes: 5 additions & 5 deletions docs/redemption-widget.md
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,7 @@ The ```data-config-id``` parameter specifies the Boson Configuration addressed b

## Using the Boson Redemption Button

As a seller you can also chose to use the Boson branded "Redeem" Button on your website, if you would like to do this, all you need to do is :
As a seller you can also choose to use the Boson branded "Redeem" Button on your website, if you would like to do this, all you need to do is:

1. Add the below 2 lines of code in HTML `<head>` section:
```
Expand Down Expand Up @@ -77,23 +77,23 @@ To add a sellerId filter to the redemption widget, add a *data-seller-id* tag to

### Integrating the Redemption Widget as an iFrame

Instead of using the Redeem Button as shown above, the redemption widget can be embedded in any web page using an iFrame HTML element.
Instead of using the Redeem Button as shown above, the redemption widget can be embedded in any web page using an iFrame HTML tag.

For instance:
```
<iframe src="https://widgets.bosonprotocol.io//#/redeem?configId=production-137-0"></iframe>
<iframe src="https://widgets.bosonprotocol.io/#/redeem?configId=production-137-0"></iframe>
```

In which case the page:
- does not need to include any specific line (like the ```<script>``` tag for ```boson-widgets.js```
- does not need to include any specific line (like the ```<script>``` tag for ```boson-widgets.js```)
- shall manage itself the logic to show and hide the iFrame, and the parameters to pass to its URL.

### Redemption Widget Parameters

The following parameters configures the widget. They must be passed in the widget URL (for instance when building an iFrame).
For instance:
```
<iframe src="https://widgets.bosonprotocol.io//#/redeem?sellerId=138&configId=production-137-0"></iframe>
<iframe src="https://widgets.bosonprotocol.io/#/redeem?sellerId=138&configId=production-137-0"></iframe>
```

When using the Redeem Button, as shown above, the parameters must be passed as HTML attributes to the Button tag. For instance:
Expand Down
22 changes: 11 additions & 11 deletions docs/redemption-widget/backend-redemption-flow.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,13 +4,13 @@

## Redemption Flow with 3rd party eCommerce backend

This flow suppose a 3r-party eCommerce system is used to manage the redemption.
This flow supposes a 3r-party eCommerce system is used to manage the redemption.

Compared to the [default flow](./default-redemption-flow.md), the main difference is that the delivery information filled by the user is sent via an HTTP POST request to a backend URL passed as a parameter (***postDeliveryInfoUrl***), instead of being sent to the Seller via XMTP.

When replying to the postDeliveryInfo request, it's possible for the backend to decide if the widget should continue to the next step or not. This can be useful:
- in case the delivery details can't be validated
- in case the flow needs to interrupt, for instance to perform Shipping Cost checkout before the on-chain transaction is submitted
- in case the flow needs to be interrupted, for instance, to perform Shipping Cost checkout before the on-chain transaction is submitted

In addition, the on-chain Redeem transaction submission and confirmation can be relayed to the backend using respective parameters ***postRedemptionSubmittedUrl*** and ***postRedemptionConfirmedUrl***.

Expand All @@ -37,7 +37,7 @@ When the Seller website activates the Redemption Widget with the adequate option
1. Wallet connection (if needed)

![Wallet connection](./../assets/redemption-widget/1-wallet-connection.png)
In case the user wallet is already connected, this step is ignored
In case the user wallet is already connected, this step is skipped

2. Redemption Overview

Expand All @@ -49,12 +49,12 @@ When the Seller website activates the Redemption Widget with the adequate option

Committed exchanges owned by the connected wallet are shown to the user, that are the rNFT owned by the wallet and that the user can redeem. In this example, the ***sellerId*** parameter is used to show only the exchanges of a unique seller.

The user select a rNFT and click it to show the "Exchange Card". Optionally, Redeem button can be directly clicked, that lead the user directly to the Redeem Form
The user selects an rNFT and clicks it to show the "Exchange Card". Optionally, the Redeem button can be directly clicked, which leads the user directly to the Redeem Form

4. Exchange Card

![Exchange Card](./../assets/redemption-widget/4-exchange-card-2.png)
This view show details about the exchange, and present a Redeem button (in case the rNFT is redeemable) that the user click to jump to the Redeem Form
This view show details about the exchange, and presents a Redeem button (in case the rNFT is redeemable) that the user can click to jump to the Redeem Form

5. Redeem Form

Expand All @@ -67,11 +67,11 @@ When the Seller website activates the Redemption Widget with the adequate option

6.1. User Signature

First, The user is asked to sign the delivery details with their wallet, to allow the backend to verify the request is coming from the real buyer.
First, the user is asked to sign the delivery details with their wallet to allow the backend to verify the request is coming from the real buyer.

6.2 POST DeliveryInfo

Once the message is signed by the wallet, an HTTP request ***post DeliverInfo*** is sent to the backend, containing the delivery information, details about the redeemed exchange, and the user signature.
Once the message is signed by the wallet an HTTP request ***post DeliverInfo*** is sent to the backend containing the delivery information, details about the redeemed exchange, and the user signature.

The backend should verify, from the signature, that the signer is the buyer wallet, then store the delivery information for this exchange.

Expand All @@ -81,11 +81,11 @@ When the Seller website activates the Redemption Widget with the adequate option

6.3 Sign/Send Redemption Transaction

Now the user is asks to click on **Confirm Redemption** to send the Redeem transaction on-chain (to be signed/confirmed by the user with their wallet)
Now the user is asked to click on **Confirm Redemption** to send the Redeem transaction on-chain (to be signed/confirmed by the user with their wallet)

6.4 POST Redemption Submitted

Once the Redeem transaction is signed by the wallet and sent on-chain, an HTTP request ***post RedemptionSubmitted*** is sent to the backend, containing the details about the redeemed exchange, and the expected transaction hash *(Note: the hash of the real transaction may be different than the expected one, for instance in case the wallet resubmits with higher fees, to speed it up)*.
Once the Redeem transaction is signed by the wallet and sent on-chain, an HTTP request ***post RedemptionSubmitted*** is sent to the backend containing the details about the redeemed exchange and the expected transaction hash *(Note: the hash of the real transaction may be different than the expected one, for instance in case the wallet resubmits with higher fees, to speed it up)*.

The backend response to this HTTP request has no effect on the widget flow.

Expand All @@ -109,7 +109,7 @@ When the Seller website activates the Redemption Widget with the adequate option

It is possible to interrupt the redemption flow between the delivery details is sent to the backend and the redeem transaction is sent on-chain.

This is useful to allow full redemption to include an additional step or verification between this 2 steps.
This is useful to allow full redemption to include an additional step or verification between these 2 steps.

Interruption is triggered by the response the backend sends back to the widget when replying to the HTTP ***post DeliverInfo*** request (step #6.2 above).

Expand All @@ -129,7 +129,7 @@ Interruption is triggered by the response the backend sends back to the widget w

The next step is, for the backend, to handle the shipping cost checkout, or any other action required at this stage.

When done, the widget can be called again, with adequate parameters, to end up the redemption flow.
When done, the widget can be called again, with adequate parameters, to end the redemption flow.

### End of Redemption confirmation, following an interrupted flow

Expand Down
12 changes: 6 additions & 6 deletions docs/redemption-widget/default-cancellation-flow.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,29 +4,29 @@

## Default Cancellation Flow

When the Seller website activate the Redemption Widget with the default options, the user is guided through the following steps:
When the Seller website activates the Redemption Widget with the default options, the user is guided through the following steps:

1. Wallet connection (if needed)
![Wallet connection](./../assets/redemption-widget/1-wallet-connection.png)
In case the user wallet is already connected, this step is ignored
In case the user wallet is already connected, this step is skipped

2. Redemption Overview
![Redemption Overview](./../assets/redemption-widget/2-redemption-overview.png)

3. Select Exchange
![Select Exchange](./../assets/redemption-widget/3-select-exchange.png)

By default, the Committed exchanges are shown to the user, that are the rNFT owned by the wallet and that the user can cancel.
By default, the Committed exchanges are shown to the user. These are the rNFT owned by the wallet and that the user can cancel.

The user select a rNFT and click it to show the "Exchange Card". Optionally, Cancel button can be directly clicked, that lead the user directly to the Cancel Form
The user selects an rNFT and clicks it to show the "Exchange Card". Optionally, Cancel button can be directly clicked, which leads the user directly to the Cancel Form

4. Exchange Card
![Exchange Card](./../assets/redemption-widget/4-exchange-card.png)
This view show details about the exchange, and present a Cancel button (in case the rNFT is cancellable) that the user clicks to jump to the Cancel Form
This view shows details about the exchange, and present a Cancel button (in case the rNFT is cancellable) that the user can click to jump to the Cancel Form

5. Cancel Form
![Cancel Form](./../assets/redemption-widget/5-cancel-form.png)
The user clicks "Confirm cancellation", that sends the CancelExchange transaction on-chain (to be signed/confirmed by the user with their wallet)
The user clicks "Confirm cancellation" which sends the CancelExchange transaction on-chain (to be signed/confirmed by the user with their wallet)

Once the Cancel transaction is confirmed on-chain, the widget goes back to the Exchange Card.

Expand Down
4 changes: 2 additions & 2 deletions docs/redemption-widget/default-redemption-flow.md
Original file line number Diff line number Diff line change
Expand Up @@ -30,9 +30,9 @@ When the Seller website activate the Redemption Widget with the default options,

6. Redeem Confirmation
![Redeem Confirmation](./../assets/redemption-widget/6-redeem-confirmation.png)
The user needs to Initialize the Chat layer (signing a message with their wallet) to allow the delivery information to be sent to the Seller. [XMTP](https://xmtp.org/) is used as a chat layer, insuring decentralization and privacy of Buyer/Seller communication
The user needs to Initialize the Chat layer (signing a message with their wallet) to allow the delivery information to be sent to the Seller. [XMTP](https://xmtp.org/) is used as a chat layer, insuring decentralization and privacy of Buyer/Seller communication.

Once the Chat is Initialized, the user clicks "Confirm address and redeem", that:
Once the Chat is Initialized, the user clicks "Confirm address and redeem", which:
- sends the delivery details to the Seller (via XMTP)
- sends the Redeem transaction on-chain (to be signed/confirmed by the user with their wallet)

Expand Down
2 changes: 1 addition & 1 deletion docs/redemption-widget/raise-dispute-flow.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,7 @@ When the Seller website activates the Redemption Widget with the appropriate par
1. Wallet connection (if needed)

![Wallet connection](./../assets/redemption-widget/1-wallet-connection.png)
In case the user wallet is already connected, this step is ignored
In case the user wallet is already connected, this step is skipped

2. Select Exchange

Expand Down

0 comments on commit 2ef2a07

Please sign in to comment.