Bug: chore(docs): remove old add_connector.md file



Remove old add_connector.md file
diff --git a/add_connector.md b/add_connector.md
index 4d6e885b7ed..4ee8c895656 100644
--- a/add_connector.md
+++ b/add_connector.md
@@ -1,384 +1,314 @@
-# Guide to Integrate a Connector
+# Guide to Integrating a Connector
+
+## Table of Contents
+
+1. [Introduction](#introduction)
+2. [Prerequisites](#prerequisites)
+3. [Understanding Connectors and Payment Methods](#understanding-connectors-and-payment-methods)
+4. [Integration Steps](#integration-steps)
+   - [Generate Template](#generate-template)
+   - [Implement Request & Response Types](#implement-request--response-types)
+   - [Implement transformers.rs](#implementing-transformersrs)
+   - [Handle Response Mapping](#handle-response-mapping)
+   - [Recommended Fields for Connector Request and Response](#recommended-fields-for-connector-request-and-response)
+   - [Error Handling](#error-handling)
+5. [Implementing the Traits](#implementing-the-traits)
+   - [ConnectorCommon](#connectorcommon)
+   - [ConnectorIntegration](#connectorintegration)
+   - [ConnectorCommonExt](#connectorcommonext)
+   - [Other Traits](#othertraits)
+6. [Set the Currency Unit](#set-the-currency-unit)
+7. [Connector utility functions](#connector-utility-functions)
+8. [Connector configs for control center](#connector-configs-for-control-center)
+9. [Update `ConnectorTypes.res` and `ConnectorUtils.res`](#update-connectortypesres-and-connectorutilsres)
+10. [Add Connector Icon](#add-connector-icon)
+11. [Test the Connector](#test-the-connector)
+12. [Build Payment Request and Response from JSON Schema](#build-payment-request-and-response-from-json-schema)
 
 ## Introduction
 
-This is a guide to contributing new connector to Router. This guide includes instructions on checking out the source code, integrating and testing the new connector, and finally contributing the new connector back to the project.
+This guide provides instructions on integrating a new connector with Router, from setting up the environment to implementing API interactions.
 
 ## Prerequisites
 
-- Understanding of the Connector APIs which you wish to integrate with Router
-- Setup of Router repository and running it on local
-- Access to API credentials for testing the Connector API (you can quickly sign up for sandbox/uat credentials by visiting the website of the connector you wish to integrate)
-- Ensure that you have the nightly toolchain installed because the connector template script includes code formatting.
-
-Install it using `rustup`:
-
-```bash
+- Familiarity with the Connector API you’re integrating
+- A locally set up and running Router repository
+- API credentials for testing (sign up for sandbox/UAT credentials on the connector’s website).
+- Rust nightly toolchain installed for code formatting:
+  ```bash
   rustup toolchain install nightly
-```
-
-In Router, there are Connectors and Payment Methods, examples of both are shown below from which the difference is apparent.
-
-### What is a Connector ?
+  ```
 
-A connector is an integration to fulfill payments. Related use cases could be any of the below
+## Understanding Connectors and Payment Methods
 
-- Payment processor (Stripe, Adyen, ChasePaymentTech etc.,)
-- Fraud and Risk management platform (like Signifyd, Riskified etc.,)
-- Payment network (Visa, Master)
-- Payment authentication services (Cardinal etc.,)
-  Currently, the router is compatible with 'Payment Processors' and 'Fraud and Risk Management' platforms. Support for additional categories will be expanded in the near future.
+A **Connector** processes payments (e.g., Stripe, Adyen) or manages fraud risk (e.g., Signifyd). A **Payment Method** is a specific way to transact (e.g., credit card, PayPal). See the [Hyperswitch Payment Matrix](https://hyperswitch.io/pm-list) for details.
 
-### What is a Payment Method ?
+## Integration Steps
 
-Every Payment Processor has the capability to accommodate various payment methods. Refer to the [Hyperswitch Payment matrix](https://hyperswitch.io/pm-list) to discover the supported processors and payment methods.
+Integrating a connector is mainly an API integration task. You'll define request and response types and implement required traits.
 
-The above mentioned payment methods are already included in Router. Hence, adding a new connector which offers payment_methods available in Router is easy and requires almost no breaking changes.
-Adding a new payment method might require some changes in core business logic of Router, which we are actively working upon.
+This tutorial covers card payments via [Billwerk](https://optimize-docs.billwerk.com/). Review the API reference and test APIs before starting.
 
-## How to Integrate a Connector
+Follow these steps to integrate a new connector.
 
-Most of the code to be written is just another API integration. You have to write request and response types for API of the connector you wish to integrate and implement required traits.
+### Generate Template
 
-For this tutorial we will be integrating card payment through the [Checkout.com connector](https://www.checkout.com/).
-Go through the [Checkout.com API reference](https://api-reference.checkout.com/). It would also be helpful to try out the API's, using tools like on postman, or any other API testing tool before starting the integration.
-
-Below is a step-by-step tutorial for integrating a new connector.
-
-### **Generate the template**
+Run the following script to create the connector structure:
 
 ```bash
 sh scripts/add_connector.sh <connector-name> <connector-base-url>
 ```
 
-For this tutorial `<connector-name>` would be `checkout`.
-
-The folder structure will be modified as below
+Example folder structure:
 
 ```
-crates/router/src/connector
-├── checkout
+hyperswitch_connectors/src/connectors
+├── billwerk
 │   └── transformers.rs
-└── checkout.rs
+└── billwerk.rs
 crates/router/tests/connectors
-└── checkout.rs
+└── billwerk.rs
 ```
 
-`crates/router/src/connector/checkout/transformers.rs` will contain connectors API Request and Response types, and conversion between the router and connector API types.
-`crates/router/src/connector/checkout.rs` will contain the trait implementations for the connector.
-`crates/router/tests/connectors/checkout.rs` will contain the basic tests for the payments flows.
+**Note:** move the file `crates/hyperswitch_connectors/src/connectors/connector_name/test.rs` to `crates/router/tests/connectors/connector_name.rs`
 
-There is boiler plate code with `todo!()` in the above mentioned files. Go through the rest of the guide and fill in code wherever necessary.
 
-### **Implementing Request and Response types**
+Define API request/response types and conversions in `hyperswitch_connectors/src/connector/billwerk/transformers.rs`
 
-Adding new Connector is all about implementing the data transformation from Router's core to Connector's API request format.
-The Connector module is implemented as a stateless module, so that you will not have to worry about persistence of data. Router core will automatically take care of data persistence.
+Implement connector traits in `hyperswitch_connectors/src/connector/billwerk.rs`
 
-Lets add code in `transformers.rs` file.
-A little planning and designing is required for implementing the Requests and Responses of the connector, as it depends on the API spec of the connector.
+Write basic payment flow tests in `crates/router/tests/connectors/billwerk.rs`
 
-For example, in case of checkout, the [request](https://api-reference.checkout.com/#tag/Payments) has a required parameter `currency` and few other required parameters in `source`. But the fields in “source” vary depending on the `source type`. An enum is needed to accommodate this in the Request type. You may need to add the serde tags to convert enum into json or url encoded based on your requirements. Here `serde(untagged)` is added to make the whole structure into the proper json acceptable to the connector.
+Boilerplate code with todo!() is provided—follow the guide and complete the necessary implementations.
 
-Now let's implement Request type for checkout
+### Implement Request & Response Types
 
-```rust
-#[derive(Debug, Serialize)]
-pub struct CardSource {
-    #[serde(rename = "type")]
-    pub source_type: CheckoutSourceTypes,
-    pub number: cards::CardNumber,
-    pub expiry_month: Secret<String>,
-    pub expiry_year: Secret<String>,
-    pub cvv: Secret<String>,
-}
+Integrating a new connector involves transforming Router's core data into the connector's API format. Since the Connector module is stateless, Router handles data persistence.
+
+#### Implementing transformers.rs
+
+Design request/response structures based on the connector's API spec.
 
+Define request format in `transformers.rs`:
+
+```rust
 #[derive(Debug, Serialize)]
-#[serde(untagged)]
-pub enum PaymentSource {
-    Card(CardSource),
-    Wallets(WalletSource),
-    ApplePayPredecrypt(Box<ApplePayPredecrypt>),
+pub struct BillwerkCustomerObject {
+    handle: Option<id_type::CustomerId>,
+    email: Option<Email>,
+    address: Option<Secret<String>>,
+    address2: Option<Secret<String>>,
+    city: Option<String>,
+    country: Option<common_enums::CountryAlpha2>,
+    first_name: Option<Secret<String>>,
+    last_name: Option<Secret<String>>,
 }
 
 #[derive(Debug, Serialize)]
-pub struct PaymentsRequest {
-    pub source: PaymentSource,
-    pub amount: i64,
-    pub currency: String,
-    pub processing_channel_id: Secret<String>,
-    #[serde(rename = "3ds")]
-    pub three_ds: CheckoutThreeDS,
-    #[serde(flatten)]
-    pub return_url: ReturnUrl,
-    pub capture: bool,
-    pub reference: String,
+pub struct BillwerkPaymentsRequest {
+    handle: String,
+    amount: MinorUnit,
+    source: Secret<String>,
+    currency: common_enums::Currency,
+    customer: BillwerkCustomerObject,
+    metadata: Option<SecretSerdeValue>,
+    settle: bool,
 }
 ```
 
 Since Router is connector agnostic, only minimal data is sent to connector and optional fields may be ignored.
 
-Here processing_channel_id, is specific to checkout and implementations of such functions should be inside the checkout directory.
-Let's define `PaymentSource`
-
-`PaymentSource` is an enum type. Request types will need to derive `Serialize` and response types will need to derive `Deserialize`. For request types `From<RouterData>` needs to be implemented.
-
-For request types that involve an amount, the implementation of `TryFrom<&ConnectorRouterData<&T>>` is required:
-
-```rust
-impl TryFrom<&CheckoutRouterData<&T>> for PaymentsRequest
-```
-
-else
+We transform our `PaymentsAuthorizeRouterData` into Billwerk's `PaymentsRequest` structure by employing the `try_from` function.
 
 ```rust
-impl TryFrom<T> for PaymentsRequest
-```
-
-where `T` is a generic type which can be `types::PaymentsAuthorizeRouterData`, `types::PaymentsCaptureRouterData`, etc.
-
-In this impl block we build the request type from RouterData which will almost always contain all the required information you need for payment processing.
-`RouterData` contains all the information required for processing the payment.
-
-An example implementation for checkout.com is given below.
-
-```rust
-impl<'a> From<&types::RouterData<'a>> for CheckoutPaymentsRequest {
-    fn from(item: &types::RouterData) -> Self {
-
-        let ccard = match item.payment_method_data {
-            Some(api::PaymentMethod::Card(ref ccard)) => Some(ccard),
-            Some(api::PaymentMethod::BankTransfer) | None => None,
+impl TryFrom<&BillwerkRouterData<&types::PaymentsAuthorizeRouterData>> for BillwerkPaymentsRequest {
+    type Error = error_stack::Report<errors::ConnectorError>;
+    fn try_from(
+        item: &BillwerkRouterData<&types::PaymentsAuthorizeRouterData>,
+    ) -> Result<Self, Self::Error> {
+        if item.router_data.is_three_ds() {
+            return Err(errors::ConnectorError::NotImplemented(
+                "Three_ds payments through Billwerk".to_string(),
+            )
+            .into());
         };
-
-        let source_var = Source::Card(CardSource {
-            source_type: Some("card".to_owned()),
-            number: ccard.map(|x| x.card_number.clone()),
-            expiry_month: ccard.map(|x| x.card_exp_month.clone()),
-            expiry_year: ccard.map(|x| x.card_exp_year.clone()),
-        });
-
-        CheckoutPaymentsRequest {
-            source: source_var,
+        let source = match item.router_data.get_payment_method_token()? {
+            PaymentMethodToken::Token(pm_token) => Ok(pm_token),
+            _ => Err(errors::ConnectorError::MissingRequiredField {
+                field_name: "payment_method_token",
+            }),
+        }?;
+        Ok(Self {
+            handle: item.router_data.connector_request_reference_id.clone(),
             amount: item.amount,
-            currency: item.currency.to_string(),
-            processing_channel_id: generate_processing_channel_id(),
-        }
-
+            source,
+            currency: item.router_data.request.currency,
+            customer: BillwerkCustomerObject {
+                handle: item.router_data.customer_id.clone(),
+                email: item.router_data.request.email.clone(),
+                address: item.router_data.get_optional_billing_line1(),
+                address2: item.router_data.get_optional_billing_line2(),
+                city: item.router_data.get_optional_billing_city(),
+                country: item.router_data.get_optional_billing_country(),
+                first_name: item.router_data.get_optional_billing_first_name(),
+                last_name: item.router_data.get_optional_billing_last_name(),
+            },
+            metadata: item.router_data.request.metadata.clone().map(Into::into),
+            settle: item.router_data.request.is_auto_capture()?,
+        })
     }
 }
 ```
 
-Request side is now complete.
-Similar changes are now needed to handle response side.
-
-While implementing the Response Type, the important Enum to be defined for every connector is `PaymentStatus`.
+### Handle Response Mapping
 
-It stores the different status types that the connector can give in its response that is listed in its API spec. Below is the definition for checkout
+When implementing the response type, the key enum to define for each connector is `PaymentStatus`. It represents the different status types returned by the connector, as specified in its API spec. Below is the definition for Billwerk.
 
 ```rust
-#[derive(Default, Clone, Debug, Eq, PartialEq, Deserialize, Serialize)]
-pub enum CheckoutPaymentStatus {
+#[derive(Debug, Clone, Serialize, Deserialize, PartialEq)]
+#[serde(rename_all = "lowercase")]
+pub enum BillwerkPaymentState {
+    Created,
     Authorized,
-    #[default]
     Pending,
-    #[serde(rename = "Card Verified")]
-    CardVerified,
-    Declined,
-    Captured,
+    Settled,
+    Failed,
+    Cancelled,
 }
-```
 
-The important part is mapping it to the Router status codes.
-
-```rust
-impl ForeignFrom<(CheckoutPaymentStatus, Option<Balances>)> for enums::AttemptStatus {
-    fn foreign_from(item: (CheckoutPaymentStatus, Option<Balances>)) -> Self {
-        let (status, balances) = item;
-
-        match status {
-            CheckoutPaymentStatus::Authorized => {
-                if let Some(Balances {
-                    available_to_capture: 0,
-                }) = balances
-                {
-                    Self::Charged
-                } else {
-                    Self::Authorized
-                }
-            }
-            CheckoutPaymentStatus::Captured => Self::Charged,
-            CheckoutPaymentStatus::Declined => Self::Failure,
-            CheckoutPaymentStatus::Pending => Self::AuthenticationPending,
-            CheckoutPaymentStatus::CardVerified => Self::Pending,
+impl From<BillwerkPaymentState> for enums::AttemptStatus {
+    fn from(item: BillwerkPaymentState) -> Self {
+        match item {
+            BillwerkPaymentState::Created | BillwerkPaymentState::Pending => Self::Pending,
+            BillwerkPaymentState::Authorized => Self::Authorized,
+            BillwerkPaymentState::Settled => Self::Charged,
+            BillwerkPaymentState::Failed => Self::Failure,
+            BillwerkPaymentState::Cancelled => Self::Voided,
         }
     }
 }
 ```
 
-If you're converting ConnectorPaymentStatus to AttemptStatus without any additional conditions, you can employ the `impl From<ConnectorPaymentStatus> for enums::AttemptStatus`.
+Here are common payment attempt statuses:
 
-Note: A payment intent can have multiple payment attempts. `enums::AttemptStatus` represents the status of a payment attempt.
+- **Charged:** Payment succeeded.
+- **Pending:** Payment is processing.
+- **Failure:** Payment failed.
+- **Authorized:** Payment authorized; can be voided, captured, or partially captured.
+- **AuthenticationPending:** Customer action required.
+- **Voided:** Payment voided, funds returned to the customer.
 
-Some of the attempt status are given below
+**Note:** Default status should be `Pending`. Only explicit success or failure from the connector should mark the payment as `Charged` or `Failure`.
 
-- **Charged :** The payment attempt has succeeded.
-- **Pending :** Payment is in processing state.
-- **Failure :** The payment attempt has failed.
-- **Authorized :** Payment is authorized. Authorized payment can be voided, captured and partial captured.
-- **AuthenticationPending :** Customer action is required.
-- **Voided :** The payment was voided and never captured; the funds were returned to the customer.
-
-It is highly recommended that the default status is Pending. Only explicit failure and explicit success from the connector shall be marked as success or failure respectively.
+Define response format in `transformers.rs`:
 
 ```rust
-// Default should be Pending
-impl Default for CheckoutPaymentStatus {
-    fn default() -> Self {
-        CheckoutPaymentStatus::Pending
-    }
+#[derive(Debug, Clone, Serialize, Deserialize, PartialEq)]
+pub struct BillwerkPaymentsResponse {
+    state: BillwerkPaymentState,
+    handle: String,
+    error: Option<String>,
+    error_state: Option<String>,
 }
 ```
 
-Below is rest of the response type implementation for checkout
+We transform our `ResponseRouterData` into `PaymentsResponseData` by employing the `try_from` function.
 
 ```rust
-#[derive(Clone, Debug, Default, Eq, PartialEq, Deserialize, Serialize)]
-pub struct PaymentsResponse {
-    id: String,
-    amount: Option<i32>,
-    action_id: Option<String>,
-    status: CheckoutPaymentStatus,
-    #[serde(rename = "_links")]
-    links: Links,
-    balances: Option<Balances>,
-    reference: Option<String>,
-    response_code: Option<String>,
-    response_summary: Option<String>,
-}
-
-#[derive(Deserialize, Debug)]
-pub struct ActionResponse {
-    #[serde(rename = "id")]
-    pub action_id: String,
-    pub amount: i64,
-    #[serde(rename = "type")]
-    pub action_type: ActionType,
-    pub approved: Option<bool>,
-    pub reference: Option<String>,
-}
-
-#[derive(Debug, Deserialize)]
-#[serde(untagged)]
-pub enum PaymentsResponseEnum {
-    ActionResponse(Vec<ActionResponse>),
-    PaymentResponse(Box<PaymentsResponse>),
-}
-
-impl TryFrom<types::PaymentsResponseRouterData<PaymentsResponse>>
-    for types::PaymentsAuthorizeRouterData
+impl<F, T> TryFrom<ResponseRouterData<F, BillwerkPaymentsResponse, T, PaymentsResponseData>>
+    for RouterData<F, T, PaymentsResponseData>
 {
     type Error = error_stack::Report<errors::ConnectorError>;
     fn try_from(
-        item: types::PaymentsResponseRouterData<PaymentsResponse>,
+        item: ResponseRouterData<F, BillwerkPaymentsResponse, T, PaymentsResponseData>,
     ) -> Result<Self, Self::Error> {
-        let redirection_data = item.response.links.redirect.map(|href| {
-            services::RedirectForm::from((href.redirection_url, services::Method::Get))
-        });
-        let status = enums::AttemptStatus::foreign_from((
-            item.response.status,
-            item.data.request.capture_method,
-        ));
-        let error_response = if status == enums::AttemptStatus::Failure {
-            Some(types::ErrorResponse {
-                status_code: item.http_code,
+        let error_response = if item.response.error.is_some() || item.response.error_state.is_some()
+        {
+            Some(ErrorResponse {
                 code: item
                     .response
-                    .response_code
-                    .unwrap_or_else(|| consts::NO_ERROR_CODE.to_string()),
+                    .error_state
+                    .clone()
+                    .unwrap_or(NO_ERROR_CODE.to_string()),
                 message: item
                     .response
-                    .response_summary
-                    .clone()
-                    .unwrap_or_else(|| consts::NO_ERROR_MESSAGE.to_string()),
-                reason: item.response.response_summary,
+                    .error_state
+                    .unwrap_or(NO_ERROR_MESSAGE.to_string()),
+                reason: item.response.error,
+                status_code: item.http_code,
                 attempt_status: None,
-                connector_transaction_id: None,
+                connector_transaction_id: Some(item.response.handle.clone()),
             })
         } else {
             None
         };
-        let payments_response_data = types::PaymentsResponseData::TransactionResponse {
-            resource_id: types::ResponseId::ConnectorTransactionId(item.response.id.clone()),
-            redirection_data,
+        let payments_response = PaymentsResponseData::TransactionResponse {
+            resource_id: ResponseId::ConnectorTransactionId(item.response.handle.clone()),
+            redirection_data: Box::new(None),
             mandate_reference: Box::new(None),
             connector_metadata: None,
             network_txn_id: None,
-            connector_response_reference_id: Some(
-                item.response.reference.unwrap_or(item.response.id),
-            ),
+            connector_response_reference_id: Some(item.response.handle),
+            incremental_authorization_allowed: None,
+            charges: None,
         };
         Ok(Self {
-            status,
-            response: error_response.map_or_else(|| Ok(payments_response_data), Err),
+            status: enums::AttemptStatus::from(item.response.state),
+            response: error_response.map_or_else(|| Ok(payments_response), Err),
             ..item.data
         })
     }
 }
 ```
 
-Using an enum for a response struct in Rust is not recommended due to potential deserialization issues where the deserializer attempts to deserialize into all the enum variants. A preferable alternative is to employ a separate enum for the possible response variants and include it as a field within the response struct.
-
-Some recommended fields that needs to be set on connector request and response
+### Recommended Fields for Connector Request and Response
 
-- **connector_request_reference_id :** Most of the connectors anticipate merchants to include their own reference ID in payment requests. For instance, the merchant's reference ID in the checkout `PaymentRequest` is specified as `reference`.
+- **connector_request_reference_id:** Merchant's reference ID in the payment request (e.g., `reference` in Checkout).
 
 ```rust
   reference: item.router_data.connector_request_reference_id.clone(),
 ```
-
-- **connector_response_reference_id :** Merchants might face ambiguity when deciding which ID to use in the connector dashboard for payment identification. It is essential to populate the connector_response_reference_id with the appropriate reference ID, allowing merchants to recognize the transaction. This field can be linked to either `merchant_reference` or `connector_transaction_id`, depending on the field that the connector dashboard search functionality supports.
+- **connector_response_reference_id:** ID used for transaction identification in the connector dashboard, linked to merchant_reference or connector_transaction_id.
 
 ```rust
-  connector_response_reference_id: item.response.reference.or(Some(item.response.id))
+    connector_response_reference_id: item.response.reference.or(Some(item.response.id)),
 ```
 
-- **resource_id :** The connector assigns an identifier to a payment attempt, referred to as `connector_transaction_id`. This identifier is represented as an enum variant for the `resource_id`. If the connector does not provide a `connector_transaction_id`, the resource_id is set to `NoResponseId`.
+- **resource_id:** The connector's connector_transaction_id is used as the resource_id. If unavailable, set to NoResponseId.
 
 ```rust
-  resource_id: types::ResponseId::ConnectorTransactionId(item.response.id.clone()),
+    resource_id: types::ResponseId::ConnectorTransactionId(item.response.id.clone()),
 ```
 
-- **redirection_data :** For the implementation of a redirection flow (3D Secure, bank redirects, etc.), assign the redirection link to the `redirection_data`.
+- **redirection_data:** For redirection flows (e.g., 3D Secure), assign the redirection link.
 
 ```rust
-  let redirection_data = item.response.links.redirect.map(|href| {
-      services::RedirectForm::from((href.redirection_url, services::Method::Get))
-  });
+    let redirection_data = item.response.links.redirect.map(|href| {
+        services::RedirectForm::from((href.redirection_url, services::Method::Get))
+    });
 ```
 
-And finally the error type implementation
+### Error Handling
+
+Define error responses:
 
 ```rust
-#[derive(Default, Debug, Serialize, Deserialize, PartialEq)]
-pub struct CheckoutErrorResponse {
-    pub request_id: Option<String>,
-    #[serde(rename = "type")]
-    pub error_type: Option<String>,
-    pub error_codes: Option<Vec<String>>,
+#[derive(Debug, Serialize, Deserialize)]
+pub struct BillwerkErrorResponse {
+    pub code: Option<i32>,
+    pub error: String,
+    pub message: Option<String>,
 }
 ```
 
-Similarly for every API endpoint you can implement request and response types.
-
-### **Implementing the traits**
+By following these steps, you can integrate a new connector efficiently while ensuring compatibility with Router's architecture.
 
-The `mod.rs` file contains the trait implementations where we use the types in transformers.
+## Implementing the Traits
 
-We create a struct with the connector name and have trait implementations for it.
-The following trait implementations are mandatory
+The `mod.rs` file contains trait implementations using connector types in transformers. A struct with the connector name holds these implementations. Below are the mandatory traits:
 
-**ConnectorCommon :** contains common description of the connector, like the base endpoint, content-type, error response handling, id, currency unit.
+### ConnectorCommon
+Contains common description of the connector, like the base endpoint, content-type, error response handling, id, currency unit.
 
 Within the `ConnectorCommon` trait, you'll find the following methods :
 
@@ -386,7 +316,7 @@ Within the `ConnectorCommon` trait, you'll find the following methods :
 
 ```rust
   fn id(&self) -> &'static str {
-      "checkout"
+      "Billwerk"
   }
 ```
 
@@ -409,126 +339,99 @@ Within the `ConnectorCommon` trait, you'll find the following methods :
 - `get_auth_header` method accepts common HTTP Authorization headers that are accepted in all `ConnectorIntegration` flows.
 
 ```rust
-  fn get_auth_header(
-      &self,
-      auth_type: &types::ConnectorAuthType,
-  ) -> CustomResult<Vec<(String, request::Maskable<String>)>, errors::ConnectorError> {
-      let auth: checkout::CheckoutAuthType = auth_type
-          .try_into()
-          .change_context(errors::ConnectorError::FailedToObtainAuthType)?;
-      Ok(vec![(
-          headers::AUTHORIZATION.to_string(),
-          format!("Bearer {}", auth.api_secret.peek()).into_masked(),
-      )])
-  }
+    fn get_auth_header(
+        &self,
+        auth_type: &ConnectorAuthType,
+    ) -> CustomResult<Vec<(String, masking::Maskable<String>)>, errors::ConnectorError> {
+        let auth = BillwerkAuthType::try_from(auth_type)
+            .change_context(errors::ConnectorError::FailedToObtainAuthType)?;
+        let encoded_api_key = BASE64_ENGINE.encode(format!("{}:", auth.api_key.peek()));
+        Ok(vec![(
+            headers::AUTHORIZATION.to_string(),
+            format!("Basic {encoded_api_key}").into_masked(),
+        )])
+    }
 ```
 
 - `base_url` method is for fetching the base URL of connector's API. Base url needs to be consumed from configs.
 
 ```rust
-  fn base_url<'a>(&self, connectors: &'a settings::Connectors) -> &'a str {
-      connectors.checkout.base_url.as_ref()
-  }
+    fn base_url<'a>(&self, connectors: &'a Connectors) -> &'a str {
+        connectors.billwerk.base_url.as_ref()
+    }
 ```
 
 - `build_error_response` method is common error response handling for a connector if it is same in all cases
 
 ```rust
-  fn build_error_response(
-      &self,
-      res: types::Response,
-      event_builder: Option<&mut ConnectorEvent>,
-  ) -> CustomResult<types::ErrorResponse, errors::ConnectorError> {
-      let response: checkout::ErrorResponse = if res.response.is_empty() {
-          let (error_codes, error_type) = if res.status_code == 401 {
-              (
-                  Some(vec!["Invalid api key".to_string()]),
-                  Some("invalid_api_key".to_string()),
-              )
-          } else {
-              (None, None)
-          };
-          checkout::ErrorResponse {
-              request_id: None,
-              error_codes,
-              error_type,
-          }
-      } else {
-          res.response
-              .parse_struct("ErrorResponse")
-              .change_context(errors::ConnectorError::ResponseDeserializationFailed)?
-      };
-
-      router_env::logger::info!(error_response=?response);
-      let errors_list = response.error_codes.clone().unwrap_or_default();
-      let option_error_code_message = conn_utils::get_error_code_error_message_based_on_priority(
-          self.clone(),
-          errors_list
-              .into_iter()
-              .map(|errors| errors.into())
-              .collect(),
-      );
-      Ok(types::ErrorResponse {
-          status_code: res.status_code,
-          code: option_error_code_message
-              .clone()
-              .map(|error_code_message| error_code_message.error_code)
-              .unwrap_or(consts::NO_ERROR_CODE.to_string()),
-          message: option_error_code_message
-              .map(|error_code_message| error_code_message.error_message)
-              .unwrap_or(consts::NO_ERROR_MESSAGE.to_string()),
-          reason: response
-              .error_codes
-              .map(|errors| errors.join(" & "))
-              .or(response.error_type),
-          attempt_status: None,
-          connector_transaction_id: None,
-      })
-  }
+    fn build_error_response(
+        &self,
+        res: Response,
+        event_builder: Option<&mut ConnectorEvent>,
+    ) -> CustomResult<ErrorResponse, errors::ConnectorError> {
+        let response: BillwerkErrorResponse = res
+            .response
+            .parse_struct("BillwerkErrorResponse")
+            .change_context(errors::ConnectorError::ResponseDeserializationFailed)?;
+
+        event_builder.map(|i| i.set_response_body(&response));
+        router_env::logger::info!(connector_response=?response);
+
+        Ok(ErrorResponse {
+            status_code: res.status_code,
+            code: response
+                .code
+                .map_or(NO_ERROR_CODE.to_string(), |code| code.to_string()),
+            message: response.message.unwrap_or(NO_ERROR_MESSAGE.to_string()),
+            reason: Some(response.error),
+            attempt_status: None,
+            connector_transaction_id: None,
+        })
+    }
 ```
 
-**ConnectorIntegration :** For every api endpoint contains the url, using request transform and response transform and headers.
+### ConnectorIntegration
+For every api endpoint contains the url, using request transform and response transform and headers.
 Within the `ConnectorIntegration` trait, you'll find the following methods implemented(below mentioned is example for authorized flow):
 
 - `get_url` method defines endpoint for authorize flow, base url is consumed from `ConnectorCommon` trait.
 
 ```rust
-  fn get_url(
-      &self,
-      _req: &types::PaymentsAuthorizeRouterData,
-      connectors: &settings::Connectors,
-  ) -> CustomResult<String, errors::ConnectorError> {
-      Ok(format!("{}{}", self.base_url(connectors), "payments"))
-  }
+    fn get_url(
+        &self,
+        _req: &TokenizationRouterData,
+        connectors: &Connectors,
+    ) -> CustomResult<String, errors::ConnectorError> {
+        let base_url = connectors
+            .billwerk
+            .secondary_base_url
+            .as_ref()
+            .ok_or(errors::ConnectorError::FailedToObtainIntegrationUrl)?;
+        Ok(format!("{base_url}v1/token"))
+    }
 ```
 
 - `get_headers` method accepts HTTP headers that are accepted for authorize flow. In this context, it is utilized from the `ConnectorCommonExt` trait, as the connector adheres to common headers across various flows.
 
 ```rust
-  fn get_headers(
-      &self,
-      req: &types::PaymentsAuthorizeRouterData,
-      connectors: &settings::Connectors,
-  ) -> CustomResult<Vec<(String, request::Maskable<String>)>, errors::ConnectorError> {
-      self.build_headers(req, connectors)
-  }
+    fn get_headers(
+        &self,
+        req: &TokenizationRouterData,
+        connectors: &Connectors,
+    ) -> CustomResult<Vec<(String, masking::Maskable<String>)>, errors::ConnectorError> {
+        self.build_headers(req, connectors)
+    }
 ```
 
-- `get_request_body` method calls transformers where hyperswitch payment request data is transformed into connector payment request. If the conversion and construction processes are successful, the function wraps the constructed connector_req in a Box and returns it as `RequestContent::Json`. The `RequestContent` enum defines different types of request content that can be sent. It includes variants for JSON, form-urlencoded, XML, raw bytes, and potentially other formats.
+- `get_request_body` method uses transformers to convert the Hyperswitch payment request to the connector's format. If successful, it returns the request as `RequestContent::Json`, supporting formats like JSON, form-urlencoded, XML, and raw bytes.
 
 ```rust
-  fn get_request_body(
+    fn get_request_body(
         &self,
-        req: &types::PaymentsAuthorizeRouterData,
-        _connectors: &settings::Connectors,
+        req: &TokenizationRouterData,
+        _connectors: &Connectors,
     ) -> CustomResult<RequestContent, errors::ConnectorError> {
-        let connector_router_data = checkout::CheckoutRouterData::try_from((
-            &self.get_currency_unit(),
-            req.request.currency,
-            req.request.amount,
-            req,
-        ))?;
-        let connector_req = checkout::PaymentsRequest::try_from(&connector_router_data)?;
+        let connector_req = BillwerkTokenRequest::try_from(req)?;
         Ok(RequestContent::Json(Box::new(connector_req)))
     }
 ```
@@ -536,91 +439,89 @@ Within the `ConnectorIntegration` trait, you'll find the following methods imple
 - `build_request` method assembles the API request by providing the method, URL, headers, and request body as parameters.
 
 ```rust
-  fn build_request(
-      &self,
-      req: &types::RouterData<
-          api::Authorize,
-          types::PaymentsAuthorizeData,
-          types::PaymentsResponseData,
-      >,
-      connectors: &settings::Connectors,
-  ) -> CustomResult<Option<services::Request>, errors::ConnectorError> {
-      Ok(Some(
-          services::RequestBuilder::new()
-              .method(services::Method::Post)
-              .url(&types::PaymentsAuthorizeType::get_url(
-                  self, req, connectors,
-              )?)
-              .attach_default_headers()
-              .headers(types::PaymentsAuthorizeType::get_headers(
-                  self, req, connectors,
-              )?)
-              .body(types::PaymentsAuthorizeType::get_request_body(
-                  self, req, connectors,
-              )?)
-              .build(),
-    ))
-  }
+    fn build_request(
+        &self,
+        req: &TokenizationRouterData,
+        connectors: &Connectors,
+    ) -> CustomResult<Option<Request>, errors::ConnectorError> {
+        Ok(Some(
+            RequestBuilder::new()
+                .method(Method::Post)
+                .url(&types::TokenizationType::get_url(self, req, connectors)?)
+                .attach_default_headers()
+                .headers(types::TokenizationType::get_headers(self, req, connectors)?)
+                .set_body(types::TokenizationType::get_request_body(
+                    self, req, connectors,
+                )?)
+                .build(),
+        ))
+    }
 ```
 
 - `handle_response` method calls transformers where connector response data is transformed into hyperswitch response.
 
 ```rust
-  fn handle_response(
-      &self,
-      data: &types::PaymentsAuthorizeRouterData,
-      event_builder: Option<&mut ConnectorEvent>,
-      res: types::Response,
-  ) -> CustomResult<types::PaymentsAuthorizeRouterData, errors::ConnectorError> {
-      let response: checkout::PaymentsResponse = res
-          .response
-          .parse_struct("PaymentIntentResponse")
-          .change_context(errors::ConnectorError::ResponseDeserializationFailed)?;
+    fn handle_response(
+        &self,
+        data: &TokenizationRouterData,
+        event_builder: Option<&mut ConnectorEvent>,
+        res: Response,
+    ) -> CustomResult<TokenizationRouterData, errors::ConnectorError>
+    where
+        PaymentsResponseData: Clone,
+    {
+        let response: BillwerkTokenResponse = res
+            .response
+            .parse_struct("BillwerkTokenResponse")
+            .change_context(errors::ConnectorError::ResponseDeserializationFailed)?;
         event_builder.map(|i| i.set_response_body(&response));
-            router_env::logger::info!(connector_response=?response);
-      types::RouterData::try_from(types::ResponseRouterData {
-          response,
-          data: data.clone(),
-          http_code: res.status_code,
-      })
-      .change_context(errors::ConnectorError::ResponseHandlingFailed)
-  }
+        router_env::logger::info!(connector_response=?response);
+        RouterData::try_from(ResponseRouterData {
+            response,
+            data: data.clone(),
+            http_code: res.status_code,
+        })
+        .change_context(errors::ConnectorError::ResponseHandlingFailed)
+    }
 ```
 
 - `get_error_response` method to manage error responses. As the handling of checkout errors remains consistent across various flows, we've incorporated it from the `build_error_response` method within the `ConnectorCommon` trait.
 
 ```rust
-  fn get_error_response(
-      &self,
-      res: types::Response,
-      event_builder: Option<&mut ConnectorEvent>,
-  ) -> CustomResult<types::ErrorResponse, errors::ConnectorError> {
-      self.build_error_response(res, event_builder)
-  }
+    fn get_error_response(
+        &self,
+        res: Response,
+        event_builder: Option<&mut ConnectorEvent>,
+    ) -> CustomResult<ErrorResponse, errors::ConnectorError> {
+        self.build_error_response(res, event_builder)
+    }
 ```
 
-**ConnectorCommonExt :** An enhanced trait for `ConnectorCommon` that enables functions with a generic type. This trait includes the `build_headers` method, responsible for constructing both the common headers and the Authorization headers (retrieved from the `get_auth_header` method), returning them as a vector.
+### ConnectorCommonExt
+Adds functions with a generic type, including the `build_headers` method. This method constructs both common headers and Authorization headers (from `get_auth_header`), returning them as a vector.
 
 ```rust
-  where
-    Self: ConnectorIntegration<Flow, Request, Response>,
-{
-    fn build_headers(
-      &self,
-      req: &types::RouterData<Flow, Request, Response>,
-      _connectors: &settings::Connectors,
-  ) -> CustomResult<Vec<(String, request::Maskable<String>)>, errors::ConnectorError> {
-      let header = vec![(
-          headers::CONTENT_TYPE.to_string(),
-          self.get_content_type().to_string().into(),
-      )];
-      let mut api_key = self.get_auth_header(&req.connector_auth_type)?;
-      header.append(&mut api_key);
-      Ok(header)
-  }
-}
+    impl<Flow, Request, Response> ConnectorCommonExt<Flow, Request, Response> for Billwerk
+    where
+        Self: ConnectorIntegration<Flow, Request, Response>,
+    {
+        fn build_headers(
+            &self,
+            req: &RouterData<Flow, Request, Response>,
+            _connectors: &Connectors,
+        ) -> CustomResult<Vec<(String, masking::Maskable<String>)>, errors::ConnectorError> {
+            let mut header = vec![(
+                headers::CONTENT_TYPE.to_string(),
+                self.get_content_type().to_string().into(),
+            )];
+            let mut api_key = self.get_auth_header(&req.connector_auth_type)?;
+            header.append(&mut api_key);
+            Ok(header)
+        }
+    }
 ```
 
+### OtherTraits
 **Payment :** This trait includes several other traits and is meant to represent the functionality related to payments.
 
 **PaymentAuthorize :** This trait extends the `api::ConnectorIntegration `trait with specific types related to payment authorization.
@@ -641,14 +542,9 @@ And the below derive traits
 - **Clone**
 - **Copy**
 
-There is a trait bound to implement refunds, if you don't want to implement refunds you can mark them as `todo!()` but code panics when you initiate refunds then.
-
-Refer to other connector code for trait implementations. Mostly the rust compiler will guide you to do it easily.
-Feel free to connect with us in case of any queries and if you want to confirm the status mapping.
-
 ### **Set the currency Unit**
 
-The `get_currency_unit` function, part of the ConnectorCommon trait, enables connectors to specify their accepted currency unit as either `Base` or `Minor`. For instance, Paypal designates its currency in the base unit (for example, USD), whereas Hyperswitch processes amounts in the minor unit (for example, cents). If a connector accepts amounts in the base unit, conversion is required, as illustrated.
+Part of the `ConnectorCommon` trait, it allows connectors to specify their accepted currency unit as either `Base` or `Minor`. For example, PayPal uses the base unit (e.g., USD), while Hyperswitch uses the minor unit (e.g., cents). Conversion is required if the connector uses the base unit.
 
 ```rust
 impl<T>
@@ -677,21 +573,19 @@ impl<T>
 }
 ```
 
-**Note:** Since the amount is being converted in the aforementioned `try_from`, it is necessary to retrieve amounts from `ConnectorRouterData` in all other `try_from` instances.
-
 ### **Connector utility functions**
 
-In the `connector/utils.rs` file, you'll discover utility functions that aid in constructing connector requests and responses. We highly recommend using these helper functions for retrieving payment request fields, such as `get_billing_country`, `get_browser_info`, and `get_expiry_date_as_yyyymm`, as well as for validations, including `is_three_ds`, `is_auto_capture`, and more.
+Contains utility functions for constructing connector requests and responses. Use these helpers for retrieving fields like `get_billing_country`, `get_browser_info`, and `get_expiry_date_as_yyyymm`, as well as for validations like `is_three_ds` and `is_auto_capture`.
 
 ```rust
-  let json_wallet_data: CheckoutGooglePayData =wallet_data.get_wallet_token_as_json()?;
+  let json_wallet_data: CheckoutGooglePayData = wallet_data.get_wallet_token_as_json()?;
 ```
 
 ### **Connector configs for control center**
 
-This section is explicitly for developers who are using the [Hyperswitch Control Center](https://github.com/juspay/hyperswitch-control-center). Below is a more detailed documentation that guides you through updating the connector configuration in the `development.toml` file in Hyperswitch and running the wasm-pack build command. Please replace placeholders such as `/absolute/path/to/` with the actual absolute paths.
+This section is for developers using the [Hyperswitch Control Center](https://github.com/juspay/hyperswitch-control-center). Update the connector configuration in development.toml and run the wasm-pack build command. Replace placeholders with actual paths.
 
-1. Install wasm-pack: Run the following command to install wasm-pack:
+1. Install wasm-pack:
 
 ```bash 
 cargo install wasm-pack
@@ -699,11 +593,10 @@ cargo install wasm-pack
 
 2. Add connector configuration:
 
-   Open the `development.toml` file located at `crates/connector_configs/toml/development.toml` in your Hyperswitch project.
-
-   Locate the [stripe] section as an example and add the configuration for the `example_connector`. Here's an example:
+    Open the development.toml file located at crates/connector_configs/toml/development.toml in your Hyperswitch project.
+    Find the [stripe] section and add the configuration for example_connector. Example:
 
-   ```toml
+    ```toml
    # crates/connector_configs/toml/development.toml
 
    # Other connector configurations...
@@ -720,144 +613,57 @@ cargo install wasm-pack
 
    ```
 
-   provide the necessary configuration details for the `example_connector`. Don't forget to save the file.
-
 3. Update paths:
-
-   Replace `/absolute/path/to/hyperswitch-control-center` with the absolute path to your Hyperswitch Control Center repository and `/absolute/path/to/hyperswitch` with the absolute path to your Hyperswitch repository.
+    Replace /absolute/path/to/hyperswitch-control-center and /absolute/path/to/hyperswitch with actual paths.
 
 4. Run `wasm-pack` build:
-
-   Execute the following command in your terminal:
-
-   ```bash
-   wasm-pack build --target web --out-dir /absolute/path/to/hyperswitch-control-center/public/hyperswitch/wasm --out-name euclid /absolute/path/to/hyperswitch/crates/euclid_wasm -- --features dummy_connector
-   ```
-
-   This command builds the WebAssembly files for the `dummy_connector` feature and places them in the specified directory.
-
-Notes:
-
-- Ensure that you replace placeholders like `/absolute/path/to/` with the actual absolute paths in your file system.
-- Verify that your connector configurations in `development.toml` are correct and saved before running the `wasm-pack` command.
-- Check for any error messages during the build process and resolve them accordingly.
+    wasm-pack build --target web --out-dir /absolute/path/to/hyperswitch-control-center/public/hyperswitch/wasm --out-name euclid /absolute/path/to/hyperswitch/crates/euclid_wasm -- --features dummy_connector
 
 By following these steps, you should be able to update the connector configuration and build the WebAssembly files successfully.
 
-Certainly! Below is a detailed documentation guide on updating the `ConnectorTypes.res` and `ConnectorUtils.res` files in your [Hyperswitch Control Center](https://github.com/juspay/hyperswitch-control-center) project.
-
-Update `ConnectorTypes.res`:
-
-1. Open `ConnectorTypes.res`:
-
-   Open the `ConnectorTypes.res` file located at `src/screens/HyperSwitch/Connectors/ConnectorTypes.res` in your Hyperswitch-Control-Center project.
-
-2. Add Connector enum:
-
-   Add the new connector name enum under the `type connectorName` section. Here's an example:
-
-   ```reason
-   /* src/screens/HyperSwitch/Connectors/ConnectorTypes.res */
-
-   type connectorName =
-     | Stripe
-     | DummyConnector
-     | YourNewConnector
-     /* Add any other connector enums as needed */
-   ```
-
-   Replace `YourNewConnector` with the name of your newly added connector.
-
-3. Save the file:
-
-   Save the changes made to `ConnectorTypes.res`.
-
-Update `ConnectorUtils.res`:
-
-1. Open `ConnectorUtils.res`:
-
-   Open the `ConnectorUtils.res` file located at `src/screens/HyperSwitch/Connectors/ConnectorUtils.res` in your [Hyperswitch Control Center](https://github.com/juspay/hyperswitch-control-center) project.
-
-2. Add Connector Description:
-
-   Update the following functions in `ConnectorUtils.res`:
-
-   ```reason
-   /* src/screens/HyperSwitch/Connectors/ConnectorUtils.res */
-
-
-   let connectorList : array<connectorName> = [Stripe,YourNewConnector]
-
-
-   let getConnectorNameString = (connectorName: connectorName) =>
-     switch connectorName {
-     | Stripe => "Stripe"
-     | DummyConnector => "Dummy Connector"
-     | YourNewConnector => "Your New Connector"
-     /* Add cases for other connectors */
-     };
-
-   let getConnectorNameTypeFromString = (str: string) =>
-     switch str {
-     | "Stripe" => Stripe
-     | "Dummy Connector" => DummyConnector
-     | "Your New Connector" => YourNewConnector
-     /* Add cases for other connectors */
-     };
-
-   let getConnectorInfo = (connectorName: connectorName) =>
-     switch connectorName {
-     | Stripe => "Stripe connector description."
-     | DummyConnector => "Dummy Connector description."
-     | YourNewConnector => "Your New Connector description."
-     /* Add descriptions for other connectors */
-     };
-
-   let getDisplayNameForConnectors = (connectorName: connectorName) =>
-     switch connectorName {
-     | Stripe => "Stripe"
-     | DummyConnector => "Dummy Connector"
-     | YourNewConnector => "Your New Connector"
-     /* Add display names for other connectors */
-     };
-   ```
-
-   Adjust the strings and descriptions according to your actual connector names and descriptions.
-
-
-4. Save the File:
-
-   Save the changes made to `ConnectorUtils.res`.
-
-Notes:
-
-- Ensure that you replace placeholders like `YourNewConnector` with the actual names of your connectors.
-- Verify that your connector enums and descriptions are correctly updated.
-- Save the files after making the changes.
-
-By following these steps, you should be able to update the `ConnectorTypes.res` and `ConnectorUtils.res` files with the new connector enum and its related information.
-
-
-
-Certainly! Below is a detailed documentation guide on how to add a new connector icon under the `public/hyperswitch/Gateway` folder in your Hyperswitch-Control-Center project.
-
-Add Connector icon:
-
-1. Prepare the icon:
-
-   Prepare your connector icon in SVG format. Ensure that the icon is named in uppercase, following the convention. For example, name it `YOURCONNECTOR.SVG`.
-
-2. Open file explorer:
-
-   Open your file explorer and navigate to the `public/hyperswitch/Gateway` folder in your Hyperswitch-Control-Center project.
-
-3. Add Icon file:
-
-   Copy and paste your SVG icon file (e.g., `YOURCONNECTOR.SVG`) into the `Gateway` folder.
-
-4. Verify file structure:
-
-   Ensure that the file structure in the `Gateway` folder follows the uppercase convention. For example:
+### Update `ConnectorTypes.res` and `ConnectorUtils.res`
+
+1. **Update `ConnectorTypes.res`**:
+   - Open `src/screens/HyperSwitch/Connectors/ConnectorTypes.res`.
+   - Add your connector to the `connectorName` enum:
+     ```reason
+     type connectorName =
+       | Stripe
+       | DummyConnector
+       | YourNewConnector
+     ```
+   - Save the file.
+
+2. **Update `ConnectorUtils.res`**:
+   - Open `src/screens/HyperSwitch/Connectors/ConnectorUtils.res`.
+   - Update functions with your connector:
+     ```reason
+     let connectorList : array<connectorName> = [Stripe, YourNewConnector]
+
+     let getConnectorNameString = (connectorName: connectorName) =>
+       switch connectorName {
+       | Stripe => "Stripe"
+       | YourNewConnector => "Your New Connector"
+       };
+
+     let getConnectorInfo = (connectorName: connectorName) =>
+       switch connectorName {
+       | Stripe => "Stripe description."
+       | YourNewConnector => "Your New Connector description."
+       };
+     ```
+   - Save the file.
+
+### Add Connector Icon
+
+1. **Prepare the Icon**:  
+   Name your connector icon in uppercase (e.g., `YOURCONNECTOR.SVG`).
+
+2. **Add the Icon**:  
+   Navigate to `public/hyperswitch/Gateway` and copy your SVG icon file there.
+
+3. **Verify Structure**:  
+   Ensure the file is correctly placed in `public/hyperswitch/Gateway`:
 
    ```
    public
@@ -865,122 +671,50 @@ Add Connector icon:
        └── Gateway
            └── YOURCONNECTOR.SVG
    ```
-    Save the changes made to the `Gateway` folder.
+   Save the changes made to the `Gateway` folder.
 
+### **Test the Connector**
 
-### **Test the connector**
+1. **Template Code**  
 
-The template code script generates a test file for the connector, containing 20 sanity tests. We anticipate that you will implement these tests when adding a new connector.
+   The template script generates a test file with 20 sanity tests. Implement these tests when adding a new connector.
 
-```rust
-// Cards Positive Tests
-// Creates a payment using the manual capture flow (Non 3DS).
-#[serial_test::serial]
-#[actix_web::test]
-async fn should_only_authorize_payment() {
-    let response = CONNECTOR
-        .authorize_payment(payment_method_details(), get_default_payment_info())
-        .await
-        .expect("Authorize payment response");
-    assert_eq!(response.status, enums::AttemptStatus::Authorized);
-}
-```
-
-Utility functions for tests are also available at `tests/connector/utils`. These functions enable you to write tests with ease.
-
-```rust
-    /// For initiating payments when `CaptureMethod` is set to `Manual`
-    /// This doesn't complete the transaction, `PaymentsCapture` needs to be done manually
-    async fn authorize_payment(
-        &self,
-        payment_data: Option<types::PaymentsAuthorizeData>,
-        payment_info: Option<PaymentInfo>,
-    ) -> Result<types::PaymentsAuthorizeRouterData, Report<ConnectorError>> {
-        let integration = self.get_data().connector.get_connector_integration();
-        let mut request = self.generate_data(
-            types::PaymentsAuthorizeData {
-                confirm: true,
-                capture_method: Some(diesel_models::enums::CaptureMethod::Manual),
-                ..(payment_data.unwrap_or(PaymentAuthorizeType::default().0))
-            },
-            payment_info,
-        );
-        let tx: oneshot::Sender<()> = oneshot::channel().0;
-        let state = routes::AppState::with_storage(
-            Settings::new().unwrap(),
-            StorageImpl::PostgresqlTest,
-            tx,
-            Box::new(services::MockApiClient),
-        )
-        .await;
-        Box::pin(call_connector(request, integration)).await
+   Example test:
+   ```rust
+    #[serial_test::serial]
+    #[actix_web::test]
+    async fn should_only_authorize_payment() {
+        let response = CONNECTOR
+            .authorize_payment(payment_method_details(), get_default_payment_info())
+            .await
+            .expect("Authorize payment response");
+        assert_eq!(response.status, enums::AttemptStatus::Authorized);
     }
-```
+   ```
 
-Prior to executing tests in the shell, ensure that the API keys are configured in `crates/router/tests/connectors/sample_auth.toml` and set the environment variable `CONNECTOR_AUTH_FILE_PATH` using the export command. Avoid pushing code with exposed API keys.
+2. **Utility Functions** 
 
-```rust
-  export CONNECTOR_AUTH_FILE_PATH="/hyperswitch/crates/router/tests/connectors/sample_auth.toml"
-  cargo test --package router --test connectors -- checkout --test-threads=1
-```
+    Helper functions for tests are available in `tests/connector/utils`, making test writing easier.
 
-All tests should pass and add appropriate tests for connector specific payment flows.
+3. **Set API Keys**
 
-### **Build payment request and response from json schema**
+    Before running tests, configure API keys in sample_auth.toml and set the environment variable:
 
-Some connectors will provide [json schema](https://developer.worldpay.com/docs/access-worldpay/api/references/payments) for each request and response supported. We can directly convert that schema to rust code by using below script. On running the script a `temp.rs` file will be created in `src/connector/<connector-name>` folder
+    ```bash
+    export CONNECTOR_AUTH_FILE_PATH="/hyperswitch/crates/router/tests/connectors/sample_auth.toml"
+    cargo test --package router --test connectors -- checkout --test-threads=1
+    ```
 
-_Note: The code generated may not be production ready and might fail for some case, we have to clean up the code as per our standards._
+### **Build Payment Request and Response from JSON Schema**
 
-```bash
-brew install openapi-generator
-export CONNECTOR_NAME="<CONNECTOR-NAME>" #Change it to appropriate connector name
-export SCHEMA_PATH="<PATH-TO-JSON-SCHEMA-FILE>" #it can be json or yaml, Refer samples below
-openapi-generator generate -g rust  -i ${SCHEMA_PATH} -o temp &&  cat temp/src/models/* > crates/router/src/connector/${CONNECTOR_NAME}/temp.rs && rm -rf temp && sed -i'' -r "s/^pub use.*//;s/^pub mod.*//;s/^\/.*//;s/^.\*.*//;s/crate::models:://g;" crates/router/src/connector/${CONNECTOR_NAME}/temp.rs && cargo +nightly fmt
-```
-
-JSON example
-
-```json
-{
-  "openapi": "3.0.1",
-  "paths": {},
-  "info": {
-    "title": "",
-    "version": ""
-  },
-  "components": {
-    "schemas": {
-      "PaymentsResponse": {
-        "type": "object",
-        "properties": {
-          "outcome": {
-            "type": "string"
-          }
-        },
-        "required": ["outcome"]
-      }
-    }
-  }
-}
-```
+1. **Install OpenAPI Generator:**
+   ```bash
+   brew install openapi-generator
+   ```
 
-YAML example
-
-```yaml
----
-openapi: 3.0.1
-paths: {}
-info:
-  title: ""
-  version: ""
-components:
-  schemas:
-    PaymentsResponse:
-      type: object
-      properties:
-        outcome:
-          type: string
-      required:
-        - outcome
-```
+2. **Generate Rust Code:**
+    ```bash
+    export CONNECTOR_NAME="<CONNECTOR-NAME>"
+    export SCHEMA_PATH="<PATH-TO-SCHEMA>"
+    openapi-generator generate -g rust -i ${SCHEMA_PATH} -o temp && cat temp/src/models/* > crates/router/src/connector/${CONNECTOR_NAME}/temp.rs && rm -rf temp && sed -i'' -r "s/^pub use.*//;s/^pub mod.*//;s/^\/.*//;s/^.\*.*//;s/crate::models:://g;" crates/router/src/connector/${CONNECTOR_NAME}/temp.rs && cargo +nightly fmt
+    ```
\ No newline at end of file
diff --git a/add_connector_updated.md b/add_connector_updated.md
index 4ee8c895656..3220cac5c5f 100644
--- a/add_connector_updated.md
+++ b/add_connector_updated.md
@@ -1,720 +1,5 @@
-# Guide to Integrating a Connector
+# 📦 File Moved
 
-## Table of Contents
+This file has been renamed. Please visit the updated version here:
 
-1. [Introduction](#introduction)
-2. [Prerequisites](#prerequisites)
-3. [Understanding Connectors and Payment Methods](#understanding-connectors-and-payment-methods)
-4. [Integration Steps](#integration-steps)
-   - [Generate Template](#generate-template)
-   - [Implement Request & Response Types](#implement-request--response-types)
-   - [Implement transformers.rs](#implementing-transformersrs)
-   - [Handle Response Mapping](#handle-response-mapping)
-   - [Recommended Fields for Connector Request and Response](#recommended-fields-for-connector-request-and-response)
-   - [Error Handling](#error-handling)
-5. [Implementing the Traits](#implementing-the-traits)
-   - [ConnectorCommon](#connectorcommon)
-   - [ConnectorIntegration](#connectorintegration)
-   - [ConnectorCommonExt](#connectorcommonext)
-   - [Other Traits](#othertraits)
-6. [Set the Currency Unit](#set-the-currency-unit)
-7. [Connector utility functions](#connector-utility-functions)
-8. [Connector configs for control center](#connector-configs-for-control-center)
-9. [Update `ConnectorTypes.res` and `ConnectorUtils.res`](#update-connectortypesres-and-connectorutilsres)
-10. [Add Connector Icon](#add-connector-icon)
-11. [Test the Connector](#test-the-connector)
-12. [Build Payment Request and Response from JSON Schema](#build-payment-request-and-response-from-json-schema)
-
-## Introduction
-
-This guide provides instructions on integrating a new connector with Router, from setting up the environment to implementing API interactions.
-
-## Prerequisites
-
-- Familiarity with the Connector API you’re integrating
-- A locally set up and running Router repository
-- API credentials for testing (sign up for sandbox/UAT credentials on the connector’s website).
-- Rust nightly toolchain installed for code formatting:
-  ```bash
-  rustup toolchain install nightly
-  ```
-
-## Understanding Connectors and Payment Methods
-
-A **Connector** processes payments (e.g., Stripe, Adyen) or manages fraud risk (e.g., Signifyd). A **Payment Method** is a specific way to transact (e.g., credit card, PayPal). See the [Hyperswitch Payment Matrix](https://hyperswitch.io/pm-list) for details.
-
-## Integration Steps
-
-Integrating a connector is mainly an API integration task. You'll define request and response types and implement required traits.
-
-This tutorial covers card payments via [Billwerk](https://optimize-docs.billwerk.com/). Review the API reference and test APIs before starting.
-
-Follow these steps to integrate a new connector.
-
-### Generate Template
-
-Run the following script to create the connector structure:
-
-```bash
-sh scripts/add_connector.sh <connector-name> <connector-base-url>
-```
-
-Example folder structure:
-
-```
-hyperswitch_connectors/src/connectors
-├── billwerk
-│   └── transformers.rs
-└── billwerk.rs
-crates/router/tests/connectors
-└── billwerk.rs
-```
-
-**Note:** move the file `crates/hyperswitch_connectors/src/connectors/connector_name/test.rs` to `crates/router/tests/connectors/connector_name.rs`
-
-
-Define API request/response types and conversions in `hyperswitch_connectors/src/connector/billwerk/transformers.rs`
-
-Implement connector traits in `hyperswitch_connectors/src/connector/billwerk.rs`
-
-Write basic payment flow tests in `crates/router/tests/connectors/billwerk.rs`
-
-Boilerplate code with todo!() is provided—follow the guide and complete the necessary implementations.
-
-### Implement Request & Response Types
-
-Integrating a new connector involves transforming Router's core data into the connector's API format. Since the Connector module is stateless, Router handles data persistence.
-
-#### Implementing transformers.rs
-
-Design request/response structures based on the connector's API spec.
-
-Define request format in `transformers.rs`:
-
-```rust
-#[derive(Debug, Serialize)]
-pub struct BillwerkCustomerObject {
-    handle: Option<id_type::CustomerId>,
-    email: Option<Email>,
-    address: Option<Secret<String>>,
-    address2: Option<Secret<String>>,
-    city: Option<String>,
-    country: Option<common_enums::CountryAlpha2>,
-    first_name: Option<Secret<String>>,
-    last_name: Option<Secret<String>>,
-}
-
-#[derive(Debug, Serialize)]
-pub struct BillwerkPaymentsRequest {
-    handle: String,
-    amount: MinorUnit,
-    source: Secret<String>,
-    currency: common_enums::Currency,
-    customer: BillwerkCustomerObject,
-    metadata: Option<SecretSerdeValue>,
-    settle: bool,
-}
-```
-
-Since Router is connector agnostic, only minimal data is sent to connector and optional fields may be ignored.
-
-We transform our `PaymentsAuthorizeRouterData` into Billwerk's `PaymentsRequest` structure by employing the `try_from` function.
-
-```rust
-impl TryFrom<&BillwerkRouterData<&types::PaymentsAuthorizeRouterData>> for BillwerkPaymentsRequest {
-    type Error = error_stack::Report<errors::ConnectorError>;
-    fn try_from(
-        item: &BillwerkRouterData<&types::PaymentsAuthorizeRouterData>,
-    ) -> Result<Self, Self::Error> {
-        if item.router_data.is_three_ds() {
-            return Err(errors::ConnectorError::NotImplemented(
-                "Three_ds payments through Billwerk".to_string(),
-            )
-            .into());
-        };
-        let source = match item.router_data.get_payment_method_token()? {
-            PaymentMethodToken::Token(pm_token) => Ok(pm_token),
-            _ => Err(errors::ConnectorError::MissingRequiredField {
-                field_name: "payment_method_token",
-            }),
-        }?;
-        Ok(Self {
-            handle: item.router_data.connector_request_reference_id.clone(),
-            amount: item.amount,
-            source,
-            currency: item.router_data.request.currency,
-            customer: BillwerkCustomerObject {
-                handle: item.router_data.customer_id.clone(),
-                email: item.router_data.request.email.clone(),
-                address: item.router_data.get_optional_billing_line1(),
-                address2: item.router_data.get_optional_billing_line2(),
-                city: item.router_data.get_optional_billing_city(),
-                country: item.router_data.get_optional_billing_country(),
-                first_name: item.router_data.get_optional_billing_first_name(),
-                last_name: item.router_data.get_optional_billing_last_name(),
-            },
-            metadata: item.router_data.request.metadata.clone().map(Into::into),
-            settle: item.router_data.request.is_auto_capture()?,
-        })
-    }
-}
-```
-
-### Handle Response Mapping
-
-When implementing the response type, the key enum to define for each connector is `PaymentStatus`. It represents the different status types returned by the connector, as specified in its API spec. Below is the definition for Billwerk.
-
-```rust
-#[derive(Debug, Clone, Serialize, Deserialize, PartialEq)]
-#[serde(rename_all = "lowercase")]
-pub enum BillwerkPaymentState {
-    Created,
-    Authorized,
-    Pending,
-    Settled,
-    Failed,
-    Cancelled,
-}
-
-impl From<BillwerkPaymentState> for enums::AttemptStatus {
-    fn from(item: BillwerkPaymentState) -> Self {
-        match item {
-            BillwerkPaymentState::Created | BillwerkPaymentState::Pending => Self::Pending,
-            BillwerkPaymentState::Authorized => Self::Authorized,
-            BillwerkPaymentState::Settled => Self::Charged,
-            BillwerkPaymentState::Failed => Self::Failure,
-            BillwerkPaymentState::Cancelled => Self::Voided,
-        }
-    }
-}
-```
-
-Here are common payment attempt statuses:
-
-- **Charged:** Payment succeeded.
-- **Pending:** Payment is processing.
-- **Failure:** Payment failed.
-- **Authorized:** Payment authorized; can be voided, captured, or partially captured.
-- **AuthenticationPending:** Customer action required.
-- **Voided:** Payment voided, funds returned to the customer.
-
-**Note:** Default status should be `Pending`. Only explicit success or failure from the connector should mark the payment as `Charged` or `Failure`.
-
-Define response format in `transformers.rs`:
-
-```rust
-#[derive(Debug, Clone, Serialize, Deserialize, PartialEq)]
-pub struct BillwerkPaymentsResponse {
-    state: BillwerkPaymentState,
-    handle: String,
-    error: Option<String>,
-    error_state: Option<String>,
-}
-```
-
-We transform our `ResponseRouterData` into `PaymentsResponseData` by employing the `try_from` function.
-
-```rust
-impl<F, T> TryFrom<ResponseRouterData<F, BillwerkPaymentsResponse, T, PaymentsResponseData>>
-    for RouterData<F, T, PaymentsResponseData>
-{
-    type Error = error_stack::Report<errors::ConnectorError>;
-    fn try_from(
-        item: ResponseRouterData<F, BillwerkPaymentsResponse, T, PaymentsResponseData>,
-    ) -> Result<Self, Self::Error> {
-        let error_response = if item.response.error.is_some() || item.response.error_state.is_some()
-        {
-            Some(ErrorResponse {
-                code: item
-                    .response
-                    .error_state
-                    .clone()
-                    .unwrap_or(NO_ERROR_CODE.to_string()),
-                message: item
-                    .response
-                    .error_state
-                    .unwrap_or(NO_ERROR_MESSAGE.to_string()),
-                reason: item.response.error,
-                status_code: item.http_code,
-                attempt_status: None,
-                connector_transaction_id: Some(item.response.handle.clone()),
-            })
-        } else {
-            None
-        };
-        let payments_response = PaymentsResponseData::TransactionResponse {
-            resource_id: ResponseId::ConnectorTransactionId(item.response.handle.clone()),
-            redirection_data: Box::new(None),
-            mandate_reference: Box::new(None),
-            connector_metadata: None,
-            network_txn_id: None,
-            connector_response_reference_id: Some(item.response.handle),
-            incremental_authorization_allowed: None,
-            charges: None,
-        };
-        Ok(Self {
-            status: enums::AttemptStatus::from(item.response.state),
-            response: error_response.map_or_else(|| Ok(payments_response), Err),
-            ..item.data
-        })
-    }
-}
-```
-
-### Recommended Fields for Connector Request and Response
-
-- **connector_request_reference_id:** Merchant's reference ID in the payment request (e.g., `reference` in Checkout).
-
-```rust
-  reference: item.router_data.connector_request_reference_id.clone(),
-```
-- **connector_response_reference_id:** ID used for transaction identification in the connector dashboard, linked to merchant_reference or connector_transaction_id.
-
-```rust
-    connector_response_reference_id: item.response.reference.or(Some(item.response.id)),
-```
-
-- **resource_id:** The connector's connector_transaction_id is used as the resource_id. If unavailable, set to NoResponseId.
-
-```rust
-    resource_id: types::ResponseId::ConnectorTransactionId(item.response.id.clone()),
-```
-
-- **redirection_data:** For redirection flows (e.g., 3D Secure), assign the redirection link.
-
-```rust
-    let redirection_data = item.response.links.redirect.map(|href| {
-        services::RedirectForm::from((href.redirection_url, services::Method::Get))
-    });
-```
-
-### Error Handling
-
-Define error responses:
-
-```rust
-#[derive(Debug, Serialize, Deserialize)]
-pub struct BillwerkErrorResponse {
-    pub code: Option<i32>,
-    pub error: String,
-    pub message: Option<String>,
-}
-```
-
-By following these steps, you can integrate a new connector efficiently while ensuring compatibility with Router's architecture.
-
-## Implementing the Traits
-
-The `mod.rs` file contains trait implementations using connector types in transformers. A struct with the connector name holds these implementations. Below are the mandatory traits:
-
-### ConnectorCommon
-Contains common description of the connector, like the base endpoint, content-type, error response handling, id, currency unit.
-
-Within the `ConnectorCommon` trait, you'll find the following methods :
-
-- `id` method corresponds directly to the connector name.
-
-```rust
-  fn id(&self) -> &'static str {
-      "Billwerk"
-  }
-```
-
-- `get_currency_unit` method anticipates you to [specify the accepted currency unit](#set-the-currency-unit) for the connector.
-
-```rust
-  fn get_currency_unit(&self) -> api::CurrencyUnit {
-      api::CurrencyUnit::Minor
-  }
-```
-
-- `common_get_content_type` method requires you to provide the accepted content type for the connector API.
-
-```rust
-  fn common_get_content_type(&self) -> &'static str {
-      "application/json"
-  }
-```
-
-- `get_auth_header` method accepts common HTTP Authorization headers that are accepted in all `ConnectorIntegration` flows.
-
-```rust
-    fn get_auth_header(
-        &self,
-        auth_type: &ConnectorAuthType,
-    ) -> CustomResult<Vec<(String, masking::Maskable<String>)>, errors::ConnectorError> {
-        let auth = BillwerkAuthType::try_from(auth_type)
-            .change_context(errors::ConnectorError::FailedToObtainAuthType)?;
-        let encoded_api_key = BASE64_ENGINE.encode(format!("{}:", auth.api_key.peek()));
-        Ok(vec![(
-            headers::AUTHORIZATION.to_string(),
-            format!("Basic {encoded_api_key}").into_masked(),
-        )])
-    }
-```
-
-- `base_url` method is for fetching the base URL of connector's API. Base url needs to be consumed from configs.
-
-```rust
-    fn base_url<'a>(&self, connectors: &'a Connectors) -> &'a str {
-        connectors.billwerk.base_url.as_ref()
-    }
-```
-
-- `build_error_response` method is common error response handling for a connector if it is same in all cases
-
-```rust
-    fn build_error_response(
-        &self,
-        res: Response,
-        event_builder: Option<&mut ConnectorEvent>,
-    ) -> CustomResult<ErrorResponse, errors::ConnectorError> {
-        let response: BillwerkErrorResponse = res
-            .response
-            .parse_struct("BillwerkErrorResponse")
-            .change_context(errors::ConnectorError::ResponseDeserializationFailed)?;
-
-        event_builder.map(|i| i.set_response_body(&response));
-        router_env::logger::info!(connector_response=?response);
-
-        Ok(ErrorResponse {
-            status_code: res.status_code,
-            code: response
-                .code
-                .map_or(NO_ERROR_CODE.to_string(), |code| code.to_string()),
-            message: response.message.unwrap_or(NO_ERROR_MESSAGE.to_string()),
-            reason: Some(response.error),
-            attempt_status: None,
-            connector_transaction_id: None,
-        })
-    }
-```
-
-### ConnectorIntegration
-For every api endpoint contains the url, using request transform and response transform and headers.
-Within the `ConnectorIntegration` trait, you'll find the following methods implemented(below mentioned is example for authorized flow):
-
-- `get_url` method defines endpoint for authorize flow, base url is consumed from `ConnectorCommon` trait.
-
-```rust
-    fn get_url(
-        &self,
-        _req: &TokenizationRouterData,
-        connectors: &Connectors,
-    ) -> CustomResult<String, errors::ConnectorError> {
-        let base_url = connectors
-            .billwerk
-            .secondary_base_url
-            .as_ref()
-            .ok_or(errors::ConnectorError::FailedToObtainIntegrationUrl)?;
-        Ok(format!("{base_url}v1/token"))
-    }
-```
-
-- `get_headers` method accepts HTTP headers that are accepted for authorize flow. In this context, it is utilized from the `ConnectorCommonExt` trait, as the connector adheres to common headers across various flows.
-
-```rust
-    fn get_headers(
-        &self,
-        req: &TokenizationRouterData,
-        connectors: &Connectors,
-    ) -> CustomResult<Vec<(String, masking::Maskable<String>)>, errors::ConnectorError> {
-        self.build_headers(req, connectors)
-    }
-```
-
-- `get_request_body` method uses transformers to convert the Hyperswitch payment request to the connector's format. If successful, it returns the request as `RequestContent::Json`, supporting formats like JSON, form-urlencoded, XML, and raw bytes.
-
-```rust
-    fn get_request_body(
-        &self,
-        req: &TokenizationRouterData,
-        _connectors: &Connectors,
-    ) -> CustomResult<RequestContent, errors::ConnectorError> {
-        let connector_req = BillwerkTokenRequest::try_from(req)?;
-        Ok(RequestContent::Json(Box::new(connector_req)))
-    }
-```
-
-- `build_request` method assembles the API request by providing the method, URL, headers, and request body as parameters.
-
-```rust
-    fn build_request(
-        &self,
-        req: &TokenizationRouterData,
-        connectors: &Connectors,
-    ) -> CustomResult<Option<Request>, errors::ConnectorError> {
-        Ok(Some(
-            RequestBuilder::new()
-                .method(Method::Post)
-                .url(&types::TokenizationType::get_url(self, req, connectors)?)
-                .attach_default_headers()
-                .headers(types::TokenizationType::get_headers(self, req, connectors)?)
-                .set_body(types::TokenizationType::get_request_body(
-                    self, req, connectors,
-                )?)
-                .build(),
-        ))
-    }
-```
-
-- `handle_response` method calls transformers where connector response data is transformed into hyperswitch response.
-
-```rust
-    fn handle_response(
-        &self,
-        data: &TokenizationRouterData,
-        event_builder: Option<&mut ConnectorEvent>,
-        res: Response,
-    ) -> CustomResult<TokenizationRouterData, errors::ConnectorError>
-    where
-        PaymentsResponseData: Clone,
-    {
-        let response: BillwerkTokenResponse = res
-            .response
-            .parse_struct("BillwerkTokenResponse")
-            .change_context(errors::ConnectorError::ResponseDeserializationFailed)?;
-        event_builder.map(|i| i.set_response_body(&response));
-        router_env::logger::info!(connector_response=?response);
-        RouterData::try_from(ResponseRouterData {
-            response,
-            data: data.clone(),
-            http_code: res.status_code,
-        })
-        .change_context(errors::ConnectorError::ResponseHandlingFailed)
-    }
-```
-
-- `get_error_response` method to manage error responses. As the handling of checkout errors remains consistent across various flows, we've incorporated it from the `build_error_response` method within the `ConnectorCommon` trait.
-
-```rust
-    fn get_error_response(
-        &self,
-        res: Response,
-        event_builder: Option<&mut ConnectorEvent>,
-    ) -> CustomResult<ErrorResponse, errors::ConnectorError> {
-        self.build_error_response(res, event_builder)
-    }
-```
-
-### ConnectorCommonExt
-Adds functions with a generic type, including the `build_headers` method. This method constructs both common headers and Authorization headers (from `get_auth_header`), returning them as a vector.
-
-```rust
-    impl<Flow, Request, Response> ConnectorCommonExt<Flow, Request, Response> for Billwerk
-    where
-        Self: ConnectorIntegration<Flow, Request, Response>,
-    {
-        fn build_headers(
-            &self,
-            req: &RouterData<Flow, Request, Response>,
-            _connectors: &Connectors,
-        ) -> CustomResult<Vec<(String, masking::Maskable<String>)>, errors::ConnectorError> {
-            let mut header = vec![(
-                headers::CONTENT_TYPE.to_string(),
-                self.get_content_type().to_string().into(),
-            )];
-            let mut api_key = self.get_auth_header(&req.connector_auth_type)?;
-            header.append(&mut api_key);
-            Ok(header)
-        }
-    }
-```
-
-### OtherTraits
-**Payment :** This trait includes several other traits and is meant to represent the functionality related to payments.
-
-**PaymentAuthorize :** This trait extends the `api::ConnectorIntegration `trait with specific types related to payment authorization.
-
-**PaymentCapture :** This trait extends the `api::ConnectorIntegration `trait with specific types related to manual payment capture.
-
-**PaymentSync :** This trait extends the `api::ConnectorIntegration `trait with specific types related to payment retrieve.
-
-**Refund :** This trait includes several other traits and is meant to represent the functionality related to Refunds.
-
-**RefundExecute :** This trait extends the `api::ConnectorIntegration `trait with specific types related to refunds create.
-
-**RefundSync :** This trait extends the `api::ConnectorIntegration `trait with specific types related to refunds retrieve.
-
-And the below derive traits
-
-- **Debug**
-- **Clone**
-- **Copy**
-
-### **Set the currency Unit**
-
-Part of the `ConnectorCommon` trait, it allows connectors to specify their accepted currency unit as either `Base` or `Minor`. For example, PayPal uses the base unit (e.g., USD), while Hyperswitch uses the minor unit (e.g., cents). Conversion is required if the connector uses the base unit.
-
-```rust
-impl<T>
-    TryFrom<(
-        &types::api::CurrencyUnit,
-        types::storage::enums::Currency,
-        i64,
-        T,
-    )> for PaypalRouterData<T>
-{
-    type Error = error_stack::Report<errors::ConnectorError>;
-    fn try_from(
-        (currency_unit, currency, amount, item): (
-            &types::api::CurrencyUnit,
-            types::storage::enums::Currency,
-            i64,
-            T,
-        ),
-    ) -> Result<Self, Self::Error> {
-        let amount = utils::get_amount_as_string(currency_unit, amount, currency)?;
-        Ok(Self {
-            amount,
-            router_data: item,
-        })
-    }
-}
-```
-
-### **Connector utility functions**
-
-Contains utility functions for constructing connector requests and responses. Use these helpers for retrieving fields like `get_billing_country`, `get_browser_info`, and `get_expiry_date_as_yyyymm`, as well as for validations like `is_three_ds` and `is_auto_capture`.
-
-```rust
-  let json_wallet_data: CheckoutGooglePayData = wallet_data.get_wallet_token_as_json()?;
-```
-
-### **Connector configs for control center**
-
-This section is for developers using the [Hyperswitch Control Center](https://github.com/juspay/hyperswitch-control-center). Update the connector configuration in development.toml and run the wasm-pack build command. Replace placeholders with actual paths.
-
-1. Install wasm-pack:
-
-```bash 
-cargo install wasm-pack
-```
-
-2. Add connector configuration:
-
-    Open the development.toml file located at crates/connector_configs/toml/development.toml in your Hyperswitch project.
-    Find the [stripe] section and add the configuration for example_connector. Example:
-
-    ```toml
-   # crates/connector_configs/toml/development.toml
-
-   # Other connector configurations...
-
-   [stripe]
-   [stripe.connector_auth.HeaderKey]
-   api_key="Secret Key"
-
-   # Add any other Stripe-specific configuration here
-
-   [example_connector]
-   # Your specific connector configuration for reference
-   # ...
-
-   ```
-
-3. Update paths:
-    Replace /absolute/path/to/hyperswitch-control-center and /absolute/path/to/hyperswitch with actual paths.
-
-4. Run `wasm-pack` build:
-    wasm-pack build --target web --out-dir /absolute/path/to/hyperswitch-control-center/public/hyperswitch/wasm --out-name euclid /absolute/path/to/hyperswitch/crates/euclid_wasm -- --features dummy_connector
-
-By following these steps, you should be able to update the connector configuration and build the WebAssembly files successfully.
-
-### Update `ConnectorTypes.res` and `ConnectorUtils.res`
-
-1. **Update `ConnectorTypes.res`**:
-   - Open `src/screens/HyperSwitch/Connectors/ConnectorTypes.res`.
-   - Add your connector to the `connectorName` enum:
-     ```reason
-     type connectorName =
-       | Stripe
-       | DummyConnector
-       | YourNewConnector
-     ```
-   - Save the file.
-
-2. **Update `ConnectorUtils.res`**:
-   - Open `src/screens/HyperSwitch/Connectors/ConnectorUtils.res`.
-   - Update functions with your connector:
-     ```reason
-     let connectorList : array<connectorName> = [Stripe, YourNewConnector]
-
-     let getConnectorNameString = (connectorName: connectorName) =>
-       switch connectorName {
-       | Stripe => "Stripe"
-       | YourNewConnector => "Your New Connector"
-       };
-
-     let getConnectorInfo = (connectorName: connectorName) =>
-       switch connectorName {
-       | Stripe => "Stripe description."
-       | YourNewConnector => "Your New Connector description."
-       };
-     ```
-   - Save the file.
-
-### Add Connector Icon
-
-1. **Prepare the Icon**:  
-   Name your connector icon in uppercase (e.g., `YOURCONNECTOR.SVG`).
-
-2. **Add the Icon**:  
-   Navigate to `public/hyperswitch/Gateway` and copy your SVG icon file there.
-
-3. **Verify Structure**:  
-   Ensure the file is correctly placed in `public/hyperswitch/Gateway`:
-
-   ```
-   public
-   └── hyperswitch
-       └── Gateway
-           └── YOURCONNECTOR.SVG
-   ```
-   Save the changes made to the `Gateway` folder.
-
-### **Test the Connector**
-
-1. **Template Code**  
-
-   The template script generates a test file with 20 sanity tests. Implement these tests when adding a new connector.
-
-   Example test:
-   ```rust
-    #[serial_test::serial]
-    #[actix_web::test]
-    async fn should_only_authorize_payment() {
-        let response = CONNECTOR
-            .authorize_payment(payment_method_details(), get_default_payment_info())
-            .await
-            .expect("Authorize payment response");
-        assert_eq!(response.status, enums::AttemptStatus::Authorized);
-    }
-   ```
-
-2. **Utility Functions** 
-
-    Helper functions for tests are available in `tests/connector/utils`, making test writing easier.
-
-3. **Set API Keys**
-
-    Before running tests, configure API keys in sample_auth.toml and set the environment variable:
-
-    ```bash
-    export CONNECTOR_AUTH_FILE_PATH="/hyperswitch/crates/router/tests/connectors/sample_auth.toml"
-    cargo test --package router --test connectors -- checkout --test-threads=1
-    ```
-
-### **Build Payment Request and Response from JSON Schema**
-
-1. **Install OpenAPI Generator:**
-   ```bash
-   brew install openapi-generator
-   ```
-
-2. **Generate Rust Code:**
-    ```bash
-    export CONNECTOR_NAME="<CONNECTOR-NAME>"
-    export SCHEMA_PATH="<PATH-TO-SCHEMA>"
-    openapi-generator generate -g rust -i ${SCHEMA_PATH} -o temp && cat temp/src/models/* > crates/router/src/connector/${CONNECTOR_NAME}/temp.rs && rm -rf temp && sed -i'' -r "s/^pub use.*//;s/^pub mod.*//;s/^\/.*//;s/^.\*.*//;s/crate::models:://g;" crates/router/src/connector/${CONNECTOR_NAME}/temp.rs && cargo +nightly fmt
-    ```
\ No newline at end of file
+👉 [add_connector.md](./add_connector.md)
\ No newline at end of file

## Type of Change
<!-- Put an `x` in the boxes that apply -->

- [ ] Bugfix
- [ ] New feature
- [ ] Enhancement
- [x] Refactoring
- [ ] Dependency updates
- [ ] Documentation
- [ ] CI/CD

## Description
<!-- Describe your changes in detail -->

Removed old add_connector.md file

### Additional Changes

- [ ] This PR modifies the API contract
- [ ] This PR modifies the database schema
- [ ] This PR modifies application configuration/environment variables

<!--
Provide links to the files with corresponding changes.

Following are the paths where you can find config files:
1. `config`
2. `crates/router/src/configs`
3. `loadtest/config`
-->


## Motivation and Context
<!--
Why is this change required? What problem does it solve?
If it fixes an open issue, please link to the issue here.

If you don't have an issue, we'd recommend starting with one first so the PR
can focus on the implementation (unless it is an obvious bug or documentation fix
that will have little conversation).
-->

Closes this [issue](https://github.com/juspay/hyperswitch/issues/8142)

## How did you test it?
<!--
Did you write an integration/unit/API test to verify the code changes?
Or did you test this change manually (provide relevant screenshots)?
-->


## Checklist
<!-- Put an `x` in the boxes that apply -->

- [ ] I formatted the code `cargo +nightly fmt --all`
- [ ] I addressed lints thrown by `cargo clippy`
- [ ] I reviewed the submitted code
- [ ] I added unit tests for my changes where possible
