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

# Overview

> Learn how to process incoming payments using e-wallet apps like ShopeePay and Dana on the Singapay Payment Gateway.

E-Wallet Native is a money-in payment method that allows your customers to pay directly using their e-wallet apps. When a checkout is created, the customer receives a redirect URL to authorize and complete the payment within their preferred e-wallet application.

<Note>
  **Money In Operation:** Funds are transferred from the customer's e-wallet to your SingaPay Payment Gateway account. For top-ups to customer e-wallets (Money Out), please refer to the [E-Wallet Top Up (Money Out)](/api-reference/e-wallet-money-out/introduction) documentation.
</Note>

## E-Wallet Payment Flow

The process from creating a checkout to successfully confirming a payment:

```mermaid theme={null}
sequenceDiagram
    participant M as Merchant System
    participant S as SingaPay API
    participant C as Customer
    participant E as E-Wallet Provider

    M->>S: POST /ewallet-native/{account_id}/create-checkout
    S-->>M: checkout_url & checkout_url_app

    M->>C: Redirect to e-wallet (web or deep link)
    C->>E: Authorize & complete payment

    E->>S: Payment confirmation notification
    S->>S: Update status: open → success

    S-->>M: Webhook notification (optional)
    M->>S: GET /inquiry-status (optional)
    S-->>M: Latest transaction status
```

<Steps>
  <Step title="Create Checkout">
    **Merchant System** sends a `POST /ewallet-native/{account_id}/create-checkout` request to the SingaPay API containing the bill amount, vendor, and customer information.
  </Step>

  <Step title="Receive Redirect URLs">
    **SingaPay API** responds by providing the `checkout_url` and `checkout_url_app`.
  </Step>

  <Step title="Redirect Customer">
    **Merchant System** redirects the customer using the web URL or deep link to their e-wallet app.
  </Step>

  <Step title="Authorize Payment">
    **Customer** authorizes and completes the payment within the **E-Wallet Provider** app.
  </Step>

  <Step title="Payment Notification">
    **E-Wallet Provider** sends a payment confirmation notification to the **SingaPay API**.
  </Step>

  <Step title="Process Payment">
    **SingaPay API** processes the payment internally, changing the transaction status from `open` to `success`.
  </Step>

  <Step title="Webhook Notification (Optional)">
    **SingaPay API** sends a webhook notification to the **Merchant System** to inform them that the payment has been received.
  </Step>

  <Step title="Verify Status">
    **Merchant System** can call `GET /inquiry-status` or `/list` to verify the latest payment status.
  </Step>
</Steps>

## Supported E-Wallet Vendors

<CardGroup cols={2}>
  <Card title="ShopeePay" icon="bag-shopping">
    `EWALLET_SHOPEEPAY`

    <br />

    Supports web redirect and app deep link.
  </Card>

  <Card title="Dana" icon="wallet">
    `EWALLET_DANA`

    <br />

    Supports web redirect.
  </Card>

  <Card title="OVO" icon="money-bill-wave">
    `EWALLET_OVO`

    <br />

    Supports push to pay.
  </Card>
</CardGroup>

## Transaction Status Lifecycle

Every e-wallet transaction goes through the following status lifecycle:

| Status     | Description                                                                                                                             |
| ---------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| `open`     | Checkout has been created, waiting for the customer to authorize and complete the payment via the e-wallet app. Checkout URL is active. |
| `success`  | Payment completed successfully. Funds have been received from the customer.                                                             |
| `expired`  | Checkout link has expired. Computed automatically when the `expired_at` timestamp has passed while the status is still `open`.          |
| `canceled` | Transaction was canceled before the payment was completed.                                                                              |
| `failed`   | Payment attempt failed due to an error during processing.                                                                               |

## Available endpoints

<CardGroup cols={3}>
  <Card title="Create Checkout (Legacy)" icon="plus" href="./create-v1-legacy">
    Create a new e-wallet checkout order with a redirect URL for the customer
  </Card>

  <Card title="Create Checkout v2" icon="plus" href="./create-v2">
    Create a new e-wallet checkout order with a redirect URL for the customer
  </Card>

  <Card title="List E-Wallet" icon="list" href="./list-transactions">
    Retrieve a paginated list of all e-wallet transactions for an account, with filters available.
  </Card>

  <Card title="Show E-Wallet" icon="eye" href="./show-transaction">
    Get detailed information about a specific e-wallet transaction.
  </Card>

  <Card title="Inquiry Status" icon="pen" href="./inquiry-status">
    Check and sync the latest payment status from the e-wallet vendor. This operation can trigger state changes.
  </Card>
</CardGroup>

## Important Notes

<AccordionGroup>
  <Accordion title="Checkout Expiration & Auto-Expire" icon="clock">
    By default, checkout URLs expire after **30 minutes**. You can set a custom expiration using the `expired_at` parameter. The `status_computed` field automatically shows `expired` when an open transaction's `expired_at` has passed, even if the raw status is still `open`.
  </Accordion>

  <Accordion title="Understanding Redirect URLs" icon="link">
    The API returns two types of links:

    * `checkout_url`: Used for redirecting to a web browser.
    * `checkout_url_app`: A deep link to directly open the related e-wallet app (if supported by the vendor).
  </Accordion>

  <Accordion title="Fees & Settlements" icon="coins">
    Each transaction details a `vendor_fee`, `merchant_fee`, and `net_amount` for transparent fee tracking. You can monitor reconciliation and settlement statuses via the `has_recon` and `has_settle` fields.
  </Accordion>

  <Accordion title="Data Retention & Deletion Restrictions" icon="trash">
    * Only transactions with the status `open` can be deleted. Paid or settled transactions cannot be deleted.
    * Transaction history records from the **last 1 year** are available via the API. Older records are safely archived.
  </Accordion>
</AccordionGroup>