> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fype.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

# Integration Architecture

fype is designed to be decoupled. This means your application logic remains agnostic of the underlying payment gateway.

## The Decoupled Lifecycle

The diagram below describes the typical integration flow:

```mermaid theme={null}
sequenceDiagram
 participant C as Customer (Browser)
 participant M as Merchant Server
 participant F as fype API
 participant G as Gateway (e.g. Razorpay)

 C->>M: Checkout Request
 M->>F: Create Payment (POST /v1/payments)
 F-->>M: Return checkout_url
 M-->>C: Redirect to checkout_url
 C->>F: Load Hosted Checkout
 F->>G: Initiate Gateway Order
 G-->>F: Order ID
 F-->>C: Display Payment UI
 C->>G: Submit Payment Details
 G-->>F: Payment Success/Fail (Webhook/Callback)
 F->>F: Verify & Transition State
 F-->>C: Redirect to success_url
 F->>M: Standardized Webhook (Async)
```

## Key Integration Points

### 1. Server-to-Server API

You interact with fype's REST API from your backend to create payments, fetch details, and process refunds.

### 2. Hosted Checkout

Instead of building complex payment forms for every gateway, you redirect customers to fype's hosted checkout. fype handles:

* Rendering the appropriate UI for the selected provider.
* Communicating with gateway SDKs.
* Validating signatures on the client side.
* Handling 3D Secure redirects.

### 3. Standardized Webhooks

fype acts as a translator. When a gateway sends a webhook (which varies wildly between providers), fype normalizes it into a standard `fype Event` and forwards it to your server.

### 4. Idempotency

For all state-changing operations (like creating a payment), fype supports the `Idempotency-Key` header. If your server retries a request due to a network timeout, fype ensures you don't create duplicate payments for the same intent.