> ## Documentation Index > Fetch the complete documentation index at: https://requestnetwork-update-banner.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Lifecycle of a Request > The typical lifecycle of a request is as follows: ![Typical Lifecycle of a Request](https://docs.request.network/~gitbook/image?url=https%3A%2F%2F1914277788-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252Fei6UAiSK3iAAi0mFH667%252Fuploads%252Fgit-blob-bb17b9b51fa3361ad54d1ac2185323f707ac8766%252FLifecycle%2520of%2520a%2520Request.jpg%3Falt%3Dmedia\&width=768\&dpr=4\&quality=100\&sign=b63df9bb\&sv=2) ## Create a request * The payer or payee signs the request which contains the payee, payer, currency, amount, payment details, and arbitrary content data. * The request can be optionally encrypted such that only the payee, payer, and approved 3rd parties can view the request contents. * The request is persisted in IPFS. * The IPFS Content-addressable ID (CID) is stored in a smart contract on Gnosis chain Requests are *created* by storing their CIDs on Gnosis, but this doesn't mean *payment* must occur on Gnosis. *Payment* can occur on any of the supported chains including 20+ EVM-compatible chains or NEAR. ## Update a request * The payee can optionally cancel the request or increase/decrease the expected amount. * The payer can optionally accept the request, indicating that they intend to pay it. * Both payee and payer can add third-party stakeholders if the request is encrypted. ## Pay a request * The payer derives a paymentReference from the request contents. * The payer calls a function on the payment network smart contract, passing in the token address, to address, amount, and paymentReference. * An event is emitted containing the token address, to address, amount, and paymentReference. Most requests are "reference-based" meaning that a paymentReference derived from the request contents is logged on-chain via a smart contract that emits an event. Nothing gets written back to IPFS when paying a "reference-based" request. The exception is when paying a "declarative" request, in which case, data *is* written back to IPFS. This includes when the payer declares that the payment was sent and the payee declares that the payment was received. ## Retrieve a request / Detect a payment * The event is indexed by the payments subgraph * An app can retrieve the request contents from IPFS and calculate the balance based on events from the payments subgraph. The request balance is calculated by adding up all the on-chain payment events with the same paymentReference. Partial payments are possible. All of these steps are facilitated by the Request Network JavaScript SDK such that the developer needs only make a few function calls. See the [Quickstart](https://docs.request.network/advanced/request-network-sdk/get-started/quickstart-browser) to learn more.