
## 👋 Welcome to Introduction to Web Sockets

> _Once upon a time when internet was at it's development phase, there lived a man named Abhaya who had a girlfriend ( imaginary ofcourse 🥲), he wanted to talk to his girlfriend. Being a developer, Abhaya created an app using http method. He created a database where he would store all the chats and he would then fetch all the data and then render on a screen. Such was his invention, which in future came to be known as chatting App._
>
> _But as always, his girlfriend shouted at him : "What Rubbish website have you built! I have to Refresh the website everytime to check if you have sent any new message to me or not..." These words made Abhaya question himself "Is this method correct ?"_
>
> _This lead Abhaya to go back to the fundamentals of the Request and Response and the channel by which this communication is made. He then decided to make a new type of connection which will ensure the connection to be open till he and his girlfriend chat and not to close this till they had shared all their stories. This type of connection later came to be known as **Web Socket Connections**._

Hello Everyone!, hope you liked the story 😂
My name is Abhaya Shankar and I will be your instructor for this short crash course where I will teach you all you need to know before you start working with websockets.

## 📖 What You will be learning ?

1. What are widely used network protocols and how do they work ?
2. What is the difference between HTTP Polling, HTTP Streaming, SSE, and Web Sockets ?
3. Working of Web Sockets...
4. How exactly do websockets work?
5. How to create websockets.
6. Real-time Examples where Web sockets are used.
7. Scenarios where you should be using websockets and where not to.

## 🤏 Prerequisites

- If you have worked with javascript and React, then you will be good to go.
- Basic knowledge of Nodejs. (Beginners also can follow this)
- You need to have [Node](https://nodejs.org/en) installed.
- Interest to learn something new 💡.
- And a cup of coffee. ☕

### 🛜 Network Protocols and their Working

Before we start our topic on websockets, it's essential to know about the different protocols and why the need for web sockets came in the first place.

There are fair share of protocols used on day-to-day basis but we remain to seem unfamiliarised with them. Let's quickly talk about them and we will then jump back to our discussion here. We are going to talk about all the protocols but our discussion will be limited to the protocols which concerns to this topic. To name a few they are **HTTP/HTTPS**, **TCP**, **IP** and **UDP**.

1. **HTTP/HTTPS** : Which stands for HyperText Transfer Protocol ( HTTP ) is an Application layer protocol used for transmitting hypertexts docs such as HTML. It is the foundation of data communication on the World Wide Web and is essential for web development. Both HTTP and HTTPS are used for transferring data over the web.

The key difference between _HTTP_ and _HTTPS_ is **Security**. HTTPS stands for HyperText Transfer Protocol Secure. It uses a secure, encrypted connection, typically using SSL (Secure Sockets Layer) or its successor, TLS (Transport Layer Security). This encryption ensures that the data exchanged between the client and server is encrypted, providing confidentiality and integrity.

2. **TCP/IP** : Which stands for Transmission Control Protocol / Internet Protocol specifies how devices exchange data over the internet. They are the fundamental suite of protocols for communication on the internet. TCP ensures reliable, ordered, and error-checked delivery of data.

The _TCP_ defines how application create communication channels and also manages how the data can be broken down into different packets/packages to be then transmitted over the internet and then re-assemble at the destination.

_IP_ defines how to address and route each packet/packages to ensures they are received at the destination.

They are designed for network reliability and auto recovery from failures. If suppose a packet which has to be received at the destination, for some reason didn't arrive at the destination, then the TCP/IP will ensure to look for the lost packet and recover it over the internet.

> In Short **TCP** is designed to ensure reliable and ordered delivery of data. If a packet is lost in transit, TCP employs retransmission mechanisms, flow control, and congestion control to recover the lost data. These mechanisms contribute to the robustness and reliability of **TCP/IP-based** communication over networks, making it suitable for applications that require accurate and complete data delivery.

3. **UDP** : Stands for User Datagram Protocol. Its working is quite similar to TCP/IP. Here also the data is broken down into packets ( referred to as **datagrams** ) in the case of UDP protocols but UDP is connectionless, meaning it does not establish a connection before sending data. Each datagram is independent of others, making it faster but less reliable than connection-oriented protocols like TCP. It doesn't have much error checking as compared to TCP. Moreover, in transit, if a datagram is lost, it is not traceable, meaning it cannot be recovered.

> In short, **UDP** is preferred for scenarios where speed and low latency are more critical than ensuring every piece of data is delivered. Its simplicity and reduced overhead make it suitable for real-time applications and situations where occasional packet loss can be tolerated.

Hope, all that made sense to you. Now once we are familiar with these terms. Let's move back to our discussion about web sockets.

> In the modern era where internet is used more extensively than anything else, you might have used **Whatsapp**, **Facebook** and **Instagram**. Real-time messaging is one of the key features which was why there messaging social platforms are widely used.

I believe now you know about or atleast heard of HTTP/HTTPS protocol. The working of which is simple where a client sends a request to the server and the request is then processed and if everything is good, server will then send the 200 OK response. If any error or issue with the request, it will send back a 403/404/500 response error depending upon the type of error.

If all these seems gibberish to you, make sure you atleast have a basic knowledge of this. You can refer this [Link](https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview).

Let's now understand how this would actually work like with a real-scenario based example. Let's say I went to a restaurant to eat ramen 🍜.
I would then ask the waiter for a menu to check which ramen they sell and upon then order.

1. I ( client ) will then order the desired ramen and then the waiter ( connection ) will take up that order to the kitchen ( server ).

2. The chef in the kitchen will then check if they know how to prepare the order ( processing the request ) and then prepare my ramen ( response ).

3. The waiter ( connection ) will then come back to me ( client ) with the finished Ramen ( Response ).

4. If the chefs in the Kitchen don't know how to prepare the ramen then the waiter will come back with apologies ( Error 500 or 404 ) that they couldn't process the order.

Such is the working of the HTTP connections. Now if I wanted to add eggs to the ramen, I would have to call the waiter and let him pass on the message to the chef, and for every request, I would have to call the waiter again and again.

So here's the issue : The kitchen can’t send a waiter to you; it can only give the waiter a dish, or bad news, when you send the waiter over. So, for the client to get updates, the only possible way is to send request to the server.

Such was the issue which Abhaya from the story was facing while he was chatting with his girlfriend. Abhaya was sending message to the server as some request with the payload, server received the message and stored in the database. But his girlfriend had no idea whether Abhaya had sent any message or not. Only way she can get the latest message is by again sending a request to the server to get back the latest response, only then can server send back the new messages.

What if we could have a way to communicate with the chef in the kitchen directly ? Interesting right then no need of contacting the waiter again and again yeah ?

Let's take a food truck instead of a restaurant then what would happen. I would directly talk to the chef of the food truck and would tell the chef that I want to eat ramen, if he knows he would directly tell me if he knows or not. I wouldn't wait for the response to come back and if yes, he knows how to prepare later if I want to add eggs I would directly tell him that I want eggs, please add them too. This type of conversation is more profound and better. Don't you think so ?

Well, you know we are getting to web sockets right. 😂
But before going to that topic, let's discuss what other work around can be for these scenarios if not web sockets or why the need for web sockets arise.

## 🌐 HTTP Polling, HTTP Streaming and SSE

1. **HTTP Polling** : One dead simple approach to work around this issue was polling. Polling is basically categorised into 2 parts namely _SHORT POLLING_ and _LONG POLLING_.

- Short Polling is very simple, just keep spamming server after every fixed amount of time, let's say 1000ms to get back any new messages. In this client keeps calling the server for latest data is any and is acheived using _setTimeout_ and _setInterval_. Downfall of this is that it consumes server resources with a barrage of requests, and most requests will return empty if the data isn’t frequently updated.

- Overcoming this issue came Long Polling. In this method, the server also receives a request, but will respond back till it gets any new data from the server. Till then it will be in pending state and won't complete till the request is resolved termed as _hanging_. Long polling is more efficient than pinging the server repeatedly since it saves the hassle of parsing request headers, querying for new data, and sending often-empty responses. However, the server must now keep track of multiple requests and their order. Also, requests can time out, ensuring low latency, and new requests need to be issued periodically.

2. **HTTP Streaming** :This mechanism saved the pain of network latency because the initial request is kept open indefinitely. The request is never terminated, even after the server pushes the data. The first three lifecycle methods of [HTTP streaming](https://gist.github.com/CMCDragonkai/6bfade6431e9ffb7fe88) are the same in HTTP long polling.

- When the response is sent back to the client, however, the request is never terminated; the server keeps the connection open and sends new updates whenever there’s a change.

3. **SSE** : SSE stands for [Server Sent Events](https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events). Another technique for sending messages which leverages the Javascript [EventSource](https://developer.mozilla.org/en-US/docs/Web/API/EventSource) interface. SSE is a standardized form of HTTP Streaming concept. EventSource opens a persistent, one-directional connection with the server over HTTP using a special text/event-stream header and listens for messages.

- This is _almost_ what we’re looking for. Now we can now receive updates from the server! Because they’re one-directional, Server-Sent Events (SSE) are great for apps where you don’t need to send the server any data. For example, the Facebook News Feed: whenever new posts come in, the server pushes them to the timeline.

4. Web Sockets : Web Sockets are the technology that is built on full-duplex connection i.e. it allows client and server to communicate with each other in real time over TCP connection. The **Keyword** here is _two-way_ communication. Web Sockets allow client and server to trigger communication with one another gaining upper hand on Polling, Streaming and SSE Events.

Moreover, the server can keep track of each client and push messages to a subset of clients. With this technology, now Abhaya and his girlfriend can chat without any disturbances.

> **Key Points** About Web Sockets
>
> - Web Sockets are **Bi-directional** in nature
> - Web Sockets uses **TCP** connection
> - Connection developed using web sockets will last as long as client and server don't close the connection.
> - Web Sockets uses **HTTP** to initiate the connection.

## 🪄 Wooaahh! You made it this far..

Give yourself a pat on the back. You did great. If you are this far, only a few more to go till you get a complete gist of the technology we are trying to learn. You are awesome! Take a sip of coffee or tea and let's continue... 🤩🤩

## 🪄 Working of Web Sockets

![HTTP connection vs Web Socket Connection](/blogs/introduction-to-websockets/http-vs-websocket.png)

Web socket connections are established by an upgraded version of HTTP Request/Response pair. A client which wants to support a web socket connection will send a HTTP Request with the following headers :

1. **Connection: Upgrade** : The `Connection` header typically manages the persistence of the network connection beyond the current transaction. A common value for this header is `keep-alive` ensuring that the connection remains open to accommodate subsequent requests to the same server.

2. **Upgrade: WebSocket** : The `Upgrade` header is used by clients to ask the server to switch to one of the listed protocols, in descending preference order. We specify `websocket` here to signal that the client wants to establish a **WebSocket** connection.

3. **Sec-WebSocket-Key: Secret_WS_Key** : The `Sec-WebSocket-Key` is a one-time random value (a nonce) generated by the client. The value is a randomly selected 16-byte value that has been base64-encoded.

Altogether, the connection established using GET Request, looks something like this :

```
GET ws://example.com:8181/ HTTP/1.1
Host: localhost:8181
Connection: Upgrade
Pragma: no-cache
Cache-Control: no-cache
Upgrade: websocket
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: a7xkcO328466gldTuKaSUa==
```

Once a client sends the initial request to open a WebSocket connection, it waits for the server’s reply. The reply must have an `HTTP 101 Switching` Protocols response code. The `HTTP 101 Switching` Protocols response indicates that the server is switching to the protocol that the client requested in its Upgrade request header.

For establishing a web socket connection, first the client sends a request to the server. Upon receiving the request, server then returns back a response and till this response is valid, the open connection persists till any of the client disconnects. This process is called **Handshake**. With every new request, a new TCP connection is generated and the previous connection is terminated.

The Handshake from the server looks something like this :

```
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat
```

Web Sockets are such connections where the client and the server communicates with an open channel. If the server would want to transmit/send any data to the client it would do so directly.

Now if the client or server anyone closes the channel, the connection is closed.
Ex. If you have had your fair share of food and you would want to go now. You ( client ) will close this channel and the connection will be closed If the Shop owner wants to close the shop, then he will terminate the channel and the connection will be closed.

![Web Socket Connection Working](/blogs/introduction-to-websockets/websocket-connection.png)

> _Websockets are very powerful when it comes to bi-directional communication and read time updation with minimum overhead. Fragmentation makes it even more powerful and light weight. You should understand web socket protocol and what are the underline priniciples of it and how it works._

Hope this Blog helped you ... 😊

## 🤩 Congratulations! You did it 🔥🔥

Great! You have successfully completed this comprehensive blog on web sockets.
You deserve a toast 🥂. Now you can proceed with some new ideas to create a chat App using web sockets. If you have been following up and have created something, make sure to showcase your project connect with me on [LinkedIn](https://www.linkedin.com/in/abhayashankar/).

Here's the **[LINK](working-with-websockets)** to the new blog for how to create and start working with web sockets.


Introduction to Websockets


## 👋 Welcome to Styled Components

My name is Abhaya Shankar and I'll be guiding you for this short project.

## 📖 What You will be learning ?

1. How to incorporate styled components in your React Project.

## 🤏 Prerequisites


Styled Components


## 👋 Welcome to Stripe Integration

My name is Abhaya Shankar and I'll be guiding you for this short project.

## 📖 What You will be learning ?

1. How to Integrate Stripe Payment Gateway in your React Project.
2. Configuring your project environment.
3. Do's and Dont's in the project.
4. Why we use the packages and what is their significance.

## 🤏 Prerequisites

- If you have worked with javascript and React, then you will be good to go.
- Basic knowledge of Nodejs. (Beginners also can follow this)
- You need to have [Node](https://nodejs.org/en) installed.
- Make sure you install the dependent packages.
- And a cup of coffee. ☕

## ⚒️ What are we Building ?

We are building a simple project for Integrating Stripe into React Project for Payments.

Then We will Buy a Luffy gear 5 Bobblehead because I am an Anime nerd and a big fan of One Piece, you should try it too.

Well anyway, Hope you have your coffee. Take a sip of your coffee and let's build this.

## 🚀 Starting Off...

For Stripe Payment Integration we require 2 basic things - a frontend where user can enter his card details and continue to pay and a backend where the validation checks and authentication is taken care of for smooth transaction process.

## 🔧 Basic Frontend Setup

- FRONTEND : CRA Template

```bash
  npx create-react-app frontend
```

Let this install all the dependencies and create a basic CRA template. This will take 15-30 sec of time depending upon your processor and network speed, it might take more. So wait till these gets installed and in the meanwhile lets proceed with the backend setup as well.

## 🔧 Basic Backend Setup

- BACKEND - Setup

```bash
mkdir backend
cd backend
npm init -y
```

First create a backend folder where in we will write all the logic for our backend. Move into the folder and then run the `npm init -y` command. This will install a `package.json` file into backend folder.
Now once you are done with all this, lets also install the packages which we will be using for this project.

1. cors
2. express
3. stripe
4. uuid
5. nodemon
6. dotenv

To install these packages run the following command

```bash
npm i cors express stripe uuid nodemon dotenv
```

This will take hardly 30-40 secs to install and once done you should have `package.json` file looking like this.

```js
{
  "name": "backend",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "cors": "^2.8.5",
    "dotenv": "^16.3.1",
    "express": "^4.18.2",
    "nodemon": "^3.0.1",
    "stripe": "^13.2.0",
    "uuid": "^9.0.0"
  }
}
```

The package version may vary depending upon the latest release, but if you are having versions above these, you dont need to stress over this.

Let's understand why exactly do we require these packages.

- **Cors** - used for cross origin resource sharing with which a front-end client can make requests for resources to an external back-end server. The single-origin policy does not allow cross-origin requests and CORS headers are required to bypass this feature. To learn more about this, you can head over [here](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS).

- **Express** - additional package built on top of node which makes our life easier. Listening to the server. To deep dive into Expressjs, you can also recommend the [documentation](https://expressjs.com/en/starter/installing.html) or this [blog](https://vegibit.com/node-js-blog-tutorial/).

- **Stripe** - for Stripe Payment integration. Refer [docs](https://stripe.com/docs) for more info.

- **uuid** - It is used for generating a unique id for each request, so that we can ensure for every transaction request we are generating a payment flow.

- **nodemon** - It is a package which re-spins the server if any changes are made to the project and saved. Not a required package but it makes our life easier. You can install this package as a dev dependecy also if you dont want this to publish in the production. Here's how you can do this - run the `npm i --save-dev nodemon`.

- **dotenv** - This package helps us to configure and use env variables inside our project to safeguard our private keys and values.

Now once the Basic setup is clear, you just wanna change a script in `package.json` file and we will good to go.

You wanna delete this **script**

```js
"scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
```

and add the following **script** in the `package.json` file

```js
"scripts": {
    "start": "nodemon index.js"
  },
```

One final thing to do before we start implementing our backend logic. Create a `.gitignore` file inside both **Backend** root folder and **Frontend** root folder and add these below code inside them both.

```js
/node_modules
/.env
```

This will ensure that when you will be publishing your project to maybe your github repo or while deployment.

> Items inside .gitignore will be ignored and will not be accessible to other people. This is crucial as you don't want your secret keys being open to other developers and also you don't want to push your node_modules to your github repo as well.

Well Kudos! You successfully created the backend setup for this project. Give yourself a pat on the back, and lets move forward with the backend logic.

After setting up your frotend and backend, you should be ready with something like this...

![Project Setup](/blogs/stripe-payment-integration/setup.png)

## 🧠 Backend Logic

Once the basic setup is done, now we wanna setup routes and logic for the backend. Moving on with the basic setup for `index.js` file :

Note : you can call this whatever you want. Most prefer this to call `server.js`, but you can call this anything.

```js
const cors = require("cors");
const express = require("express");

// TODO: Add the pub key to configure the stripe
const stripe = require("stripe")("");
const { v4: uuidv4 } = require("uuid");

const app = express();

//middlewares
app.use(cors());
app.use(express.json());

//routes
app.get("/", (req, res) => {
  res.send("IT WORKS...");
});

//Listen
const port = process.env.PORT || 5000;

const start = async () => {
  try {
    app.listen(port, () => {
      console.log(`Server listening on PORT ${port}`);
    });
  } catch (error) {
    console.log(error);
  }
};

start();
```

Here we initialised the cors, express, uuid and stripe. Then we setup a middleware `app.use(cors())` for cross-origin resource sharing. Then we setup a basic get route to home screen and we send the response **IT WORKS** which is then displayed on the home page of the PORT 5000.

We cheated our way to send the response using `res.send()`, which we ideally don't use. Instead you could also send a proper response something like this :

```js
app.get("/", (req, res) => {
  res.status(200).json({ success: true, msg: "IT WORKS" });
});
```

```js
// index.js

const cors = require("cors");
const express = require("express");

// TODO: Add the pub key to configure the stripe
const stripe = require("stripe")("");
const { v4: uuidv4 } = require("uuid");

const app = express();

//middlewares
app.use(cors());
app.use(express.json());

//routes
app.get("/", (req, res) => {
  res.send("IT WORKS...");
});

//Listen
const port = process.env.PORT || 5000;

const start = async () => {
  try {
    app.listen(port, () => {
      console.log(`Server listening on PORT ${port}`);
    });
  } catch (error) {
    console.log(error);
  }
};

start();
```

Copy paste the file into `index.js` and then spin the server by running the command

```bash
npm start
```

This will spin up the server, open up the console and if you can see `Server is running on  port 5000` , go to `http://localhost:5000/` and if you see **IT WORKS** displayed on the screen, well you did it, You created a basic route in Express. If in case you are getting any errors, please troubleshoot. Make sure you are in the backend dir when you run `npm start`.

Now inorder to use Stripe, you need to first create an account on [Stripe](https://dashboard.stripe.com/register). If you have an account already then you can login and access the stripe dashboard which will look something like this.

![Stripe Dashboard](/blogs/stripe-payment-integration/dashboard.png)

Now once you have successfully created an account, move into **Developers** tab and look for two things mainly -

- Publishable Key
- Secret Key
  > **Publishable Key** is used in Stripe's client-side code to identify your Stripe account and create secure payment tokens. It is used for handling payment information securely in the browser without exposing sensitive data.

> **Secret Key** is private key used in Stripe's server-side code to authenticate and interact with the Stripe API on your behalf. It must be kept confidential and never shared or exposed to the client side to maintain security.

![Secret Keys](/blogs/stripe-payment-integration/secretKeys.png)

Take these two values and save this somewhere safe and we will use these later in the `index.js` backend setup. Make sure you don't share these keys specially the secret keys as this would lead to security issue for your configuration.

Now move back into your **Backend** folder where we have just created our basic route. There you want to add a function at the very top of the `index.js` file.

```js
require("dotenv").config();
```

This bit of code will enable us to access our `.env` variables in our project so as to keep our secret keys as a secret.
Create a new file inside the **Backend** folder and name it `.env` like this :

![Secret Keys](/blogs/stripe-payment-integration/env.png)

Copy your secret key from Stripe Developers dashboard and paste it inside the .env variable just like in the above presented example.

Remember - **Secret_Key** goes into _Backend_ `.env` and **Publishable_Key** goes into _Frontend_ `.env`. You can access these variables using `process.env.[Your_secret_key]`.

Add secret key inside your stripe variable in `index.js` file.

```js
const stripe = require("stripe")(process.env.STRIPE_KEY);
```

Once this setup is done, let's proceed forward.

📮 Adding a POST Route

Now we wanna create a post route which we will hit from the frontend in which we will create customer from stripe and create a charge for the customer.

Let's start with the basic setup then we will add up more functions as we proceed forward.

```js
app.get("/payment", async (req, res) => {
  try {
    // Our Logic Here...
    res.status(201).json({ msg: "Success" });
  } catch (err) {
    console.log(err);
  }
});
```

Now this is a very basic setup for a post route where we will add our logic in the try block. So without wasting any time, let's move forward with this.

1. First we want to destructure `product` and `token` which we will be getting from our frontend. Then you can check whether or not you are getting the value or not, but wait till we actually setup our frontend.
2. Then we will create an **idemPotencyKey** which ensures that transaction for a particular bill is generated only once and we don't generate different bill for the same request.
3. Then we will create a customer using Stripe. Now this will return a promise so we will use **Async/Await**. If you are not familiar with async/await you can look up to this documentation of [Javascript.info](https://javascript.info/async).
4. This create customer will take in few values where we will pass on the email and source which we will getting from our token. Once this is complete we will get back our customer.
5. Once our customer is ready, we can add a charge on the purchase. This will also return a promise, so will use `await` again. This will also take in some values where **first** one is the options which we wanna extract out of which few are compulsory like `amount` , `currency`, `customer` and the **second** one is our `idemPotencyKey`

```js
const charge = await stripe.charges.create({ options }, { idempotencyKey });
```

Add the following code block into our post route, which I will explain you each and every step of configuration.

```js
app.post("/payment", async (req, res) => {
  const { product, token } = req.body;

  // Check whether we are getting value or not.
  console.log("Product", product);
  console.log("Price", product.price);

  // Special key for ensuring a user is charged only once for his/her products.
  const idemPotencyKey = uuidv4();

  try {
    const customer = await stripe.customers.create({
      email: token.email,
      source: token.id,
    });

    const charge = await stripe.charges.create(
      {
        // Multiply by 100 because stripe takes in cent as default value and we want to have in dollars.
        amount: product.price * 100,
        currency: "usd",
        customer: customer.id,
        receipt_email: token.email,
        description: `Purchase of ${product.name}`,
        shipping: {
          name: token.card.name,
          address: {
            country: token.card.address_country,
          },
        },
      },
      { idemPotencyKey }
    );

    res.status(200).json(charge);
  } catch (err) {
    console.log(err);
  }
});
```

Well that's basically all we had to do for our Backend setup. Although it's quite basic, as you dive deep into this, you will get to know a lot more and crucial todos and not-todos but we are good for now. Now let's jump back to our Frontend.

## 🐬 Diving into Frontend

Frontend is all about appealing to the eye, but at the same time where users can get easy access and smooth experience. We are not going to build a full stack E-commerce app or something, just the important part of how to use stripe as a payment. So, we will be starting off with quite simple.

Let's move back into our **Frontend** folder and there first we wanna do is some basic cleanups. We will be removing files and content which is not important for our project. Although it's not like the end of the world but its good to remove fies and stuff which unnecessarily takes up your space. If you have worked with **CRA Template** you must be quite familiar to this process.

Removing content inside `App.js`, `reportWebVitals.js`, `setupTests.js` etc. But I am not gonna do all that. We will proceed with the Logic in Frontend not the Stylings and stuffs which I am guessing you are capable of. You can find the **source code** [here](https://github.com/AbhayaShankar/Stripe/tree/main/frontend) if you have any doubt or feel stuck somewhere.

Now before proceeding forward we will install two more dependencies into our frontend project.

1. [react-stripe-checkout](https://www.npmjs.com/package/react-stripe-checkout)
2. **CDN** for `MaterializeCSS`.

Open the terminal, make sure you are inside the frontend directory and then run the following command to install `react-stripe-checkout`.

```bash
npm i react-stripe-checkout
```

After that add this `<Link>` inside the `index.html` in Public folder of frontend.

```html
<link
  rel="stylesheet"
  href="https://cdnjs.cloudflare.com/ajax/libs/materialize/1.0.0/css/materialize.min.css"
/>
```

Add the necessary import statements and then we will create a state for our product. Ideally this will be dynamic but we are hardcoding this for now.

```js
import React, { useState } from "react";
import "./App.css";
import StripeCheckout from "react-stripe-checkout";
import cover from "./cover.webp";

function App() {
  const [product, setProduct] = useState({
    name: "Luffy gear 5 Bobblehead",
    price: 35,
    productBy: "Abhaya++",
  });

  return (
    <div className="App">
      <p>Luffy Gear 5</p>
      <img src={cover} alt="cover-img" />
      <span>{product.name}</span>
    </div>
  );
}

export default App;
```

Now For the main part - Incorporating Stripe in our Frontend where we will pass our taken value which will be accessible in our backend as well. We will be using the **StripeCheckout** which will take in a few values where two are compulsory `stripeKey` and `token` and this has to named as mentioned. You can [refer](https://www.npmjs.com/package/react-stripe-checkout) the docs.

Let's create a function **makePayment** which will send response to our backend with our token and product details. Backend will then create a charge for the Customer and once validated everything will send back a response to our frontend saying that payment is successful.

```js
function App() {
  // ... our product state

  const makePayment = async (token) => {
    const body = {
      token,
      product,
    };

    const headers = {
      "Content-Type": "application/json",
    };

    const response = await fetch("http://localhost:5000/payment", {
      method: "POST",
      headers,
      body: JSON.stringify(body),
    });

    const data = await response.json();

    // Display data for checking
    console.log(data);
  };

  return (
    <div className="App">
      <p>Luffy Gear 5</p>
      <img src={cover} alt="cover-img" />
      <span>{product.name}</span>
      <StripeCheckout
        stripeKey={process.env.REACT_APP_KEY}
        token={makePayment}
        name="Buy Bobblehead"
      >
        <button className="btn-large red darken-4"> Buy BobbleHead Now</button>
      </StripeCheckout>
    </div>
  );
}

export default App;
```

We could use these className only because we have added the cdn link of materialize css into out project.

```js
const makePayment = async (token) => {
    const body = {
      token,
      product,
    };
```

In this bit of code, you might be wondering where is this `token` coming from. Actually this token is automatically created for you by `StrikeCheckout`, you just need to ensure that your prop containing token is actually named as **token** and that's it.

Then in that we create a body containing our token and product details, configure headers as `"Content-Type": "application/json"` and then the main part where we send a fetch request to our backend server and getting the response. Then we `await` response and we get back the data.

Once everything in the frontend is done, you can spin-up the frontend project by going to terminal and running `npm start` command. make sure you are in the frontend directory while running the command or else you will get some fat error. You can visit `http://localhost:3000`, you should get this on the home screen.

![Frontend View](/blogs/stripe-payment-integration/frontend.png)

One more thing you should remember that both our frontend and backend should be up and running. We have not deployed our app so its not active. Until it's running, we will not get success payment transaction.

Click on the **Buy Bobblehead Now**

![Test Mode](/blogs/stripe-payment-integration/test.png)

You can add any dummy email and Card Number in the **Test Mode** is 4242424242424242 and you can add any dummy cvv and exp date as well and then proceed to pay.

![Dummy Values](/blogs/stripe-payment-integration/dummy.png)

![Payment Success](/blogs/stripe-payment-integration/paymentSuccess.png)

If you are getting some errors in the console, please **Troubleshoot**.

## 🤩 Congrats! You did it

Great! You have successfully completed this project.
You deserve a toast 🥂. Now you can proceed with some new ideas.
If you have been following up and have created something, make sure to showcase your project connect with me on [LinkedIn](https://www.linkedin.com/in/abhayashankar/).


UI/UX. Full-Stack. Freelance.

Featured Projects

Fitness-Hub

Genius-AI

Estates Empire

AnimxStore

Featured Blogs

Styled Components

Introduction to Websockets

Stripe Payment Integration