@depay/widgets 6.8.1 → 6.10.0

package/README.md

@@ -174,6 +174,27 @@ DePayWidgets.Payment({
 
 Checkout [DePay Web3 Payments](https://github.com/DePayFi/depay-web3-payments#pay-into-smart-contracts) and [DePay Router Smart Contract](https://github.com/DePayFi/depay-evm-router) for more details.
 
+#### fee
+
+You can configure a fee which will be applied to every payment with it's own dedicated fee receiver address.
+
+The fee will be taken from the target token and target amount (after swap, depending on your `accept` configuration).
+
+`amount`: Either percentage (e.g. `5%`, or absolute amount as BigNumber string ('100000000000000000') or pure number (2.5)
+
+`receiver`: The address that is supposed to receive the fee.
+
+```javascript
+DePayWidgets.Payment({
+  accept: [...],
+  fee: {
+    amount: '3%',
+    receiver: '0x4e260bB2b25EC6F3A59B478fCDe5eD5B8D783B02'
+  }
+});
+```
+
+
 #### track
 
 `track`
@@ -234,6 +255,22 @@ Payment tracking requests will be attempted up to 3 times by the widget and will
 
 A failed payment tracking will also call the [error callback](#error) with `{code: "TRACKING_FAILED"}`.
 
+##### Additional Polling
+
+In order to ensure a 100% coverage that users are released and forwarded within your payment flow, you will need to implement polling in addition to tracking.
+
+The `track.poll` configuration either takes an `enpoint` or a `method` (similiar to track itself).
+
+It will use the endpoint or the method to request a release every 5 seconds.
+
+You need to make sure to respond to this request with a status `404` in case the user is not to be released just yet (payment and processing on your side are not complete yet)
+or `200` if the payment has been completed and the processing on your side is done and the user can be released and forwarded withing your payment flow.
+
+In case you want to redirect the user to the next step in your system the poll endpoint needs to respond with a body containing json like: `{ forward_to: 'https://example.com/next_step_url' }`.
+
+It is not enough to rely on setting `forward_to` initially with the tracking request, you will also need to respond with `forward_to` when implementing polling
+as the entire reason for polling is to cover cases where websockets fail and the initial `forward_to` can not be communicated to the client.
+
 #### connected
 
 `connected`