Build With Us

Ways To Build With Everest

There are a few ways to build the various features of the Everest protocol into your products and services – a library package, a network oracle, and white-labeled wallet software.

Try Everest Now

Get a verified EverWallet today		Buy, Sell & Swap Crypto globally now

Payments and Identity Libraries available now:

	Integration Method
	The Everest Payments Library Through a simple include of a library package, and some light configuration you can incorporate the Everest Payments Library into your application or dapp in a surprisingly short amount of time. – Accept Payments, send payments – Offer fiat on-ramp and off-ramp – Offer swaps through a simple integration – A few lines of code to implement with your application
	The Everest Identity Oracle Leveraging the nearly universal accessability of the Chainlink oracle network, Everest has provided a quick-to-integrate process to leverage the Everest Identity Oracle from nearly anywhere in Web3. – Access a real-time query / response mechanism – Validate users provided attestations and claims – Fight Sybil attacks with Everest's Human & Unique status so your online voting is valid – Financial institutions can directly verify a user's Everest KYCed Status
	The Everest EverWallet Robust digital wallet software infrastructure offered on a white-labeled SaaS basis delivers an easy-to-integrate, easy-to-deploy, and easy-to-manage Ethereum wallet for fiat or crypto use cases. – Include multiple wallets into one interface with the EverWallet wallet array – Connect existing Web3 wallets to verify ownership – A short, simple sign up process provisions an account for simple or complex applications – Open financial accounts, to the wallet array – Store documents, claims, currencies & tokens – Custodial and non-custodial solutions available
	The Everest Identity Wallet Developers gain access to a library package which embeds the Everest Identity Wallet into any experience to enable on-the-fly wallet deduplication, identity claims issuing, identity verification, and KYCing of the user. – Provides various identity proofs to your users – Integrate directly into your apps and workflows with a few lines of code – Screen users for Human & Unique status in real time – KYC and onboard customers with a simple cross-platform, white-labeled solution.

Please read our "Terms of Service", "Privacy Policy", and "Compliance" notices prior to use of this site.

Familiarity with the OpenAPI Specification will help you understand the Everest API structure.

Which Everest Solution Is Right For You:

Everest Payments Library

Overview

Let's get started! Your available resources include:

• Overview - Steps to get setup and developing quickly

• Integration Checklist - What you will need to accomplish to integrate the Payments

• Implementation Documentation - What you need to know to include the Everest functionality in your app

The Everest Payments Library (v1.1) enables you to build features of the Everest protocol directly into your products and services through the Everest APIs, a simple way of including those functions into your application flow, and a smooth implementation process.

The Everest APIs allow authorized partner organizations to automate various tasks related to Everest profile accounts. This includes being able to initiate onboarding with the required information for enrollment, initiate transactions of various kinds, and exercise other Everest Platform functionality.

Everest provides libraries and oracles to enable partner organizations to easily, safely and securely access the APIs to make it easy to include various financial service primitives into your products and services.

This flow describes the user journey:

Below we are going to describe the general flow of using the Everest Payments Library.

What is required for integration:

• Everest SDK NPM package and Everest SDK Key / Secret

• Integration of Everest SDK NPM package into Payment Options in Dapp / Site

• Integration testing to verify that the NPM package is properly implemented and is configured with the appropriate SDK Keys for connectivity

• Integration Certification video conference with Everest personnel to verify that NPM package is configured correctly

Integration Checklist

To help out during the integration process, we've created this checklist for you to follow. This is the same checklist we will be using to ensure you have addressed all items before being granted access to the Production environment, so please be sure to complete it. Click here for a downloadable version of the checklist.

Securing the session with the session token

To secure each session there is a specific sequence that we use which is detailed in the following diagram. First you receive a temp_token, which is swapped for a public_token, which in turn is swapped for a long-lived access_token. This access_token is used for further transactions on this user's behalf.

Implement the client side component

While you're integrating the Everest Payment Library client side component, make sure that:

• Your application is configured to authenticate and post data before calling the Everest NPM package.

• You implement the Error, Success and Exit callback functions.

• You Implement the client side component to handle links with an invalid or token_required status requiring a new password or a new API Key.

• You use the token.resources field to define which tokens are available in the client side code.

Payments Library Features

The Everest Payments Library allows you to quickly add financial services to your existing app or Website.

The library will let your users accept fiat payments, make fiat payments or swap between virtual financial assets.

The Everest Payments Library provides your users for single-sign-on experience, where the user is known and KYC information already recorded and/or verified the next time they visit.

– Payment On Ramp

Fiat On Ramp: Fiat to Token - Payment Methods, Fees & Other Details

Accept Payments In Your App

The Payments Library is a turnkey solution that makes it easy for your users to purchase cryptocurrency using the world's most popular payment methods. Your customers get a fast and secure way to purchase cryptocurrency and you didn't need to get a license, secure access to liquidity pools, build your own KYC process, or checkout UI.

We provide a hosted redirect model, where through a redirect to our widget your users complete their transaction and are then returned into your website or app experience.

Users are able to pay with either debit cards or echecks from their bank accounts, two simple methods to sign up and allow for recurring transactions. The user completes a brief enrollment process, provides their payment information, confirms their transaction, and receives their VFA into their wallet within minutes.

On Ramp Widget Screens	-

Before You Go Live:

– Finish your Partnership Agreement with Everest and complete KYC

– Create your production Everest account

– Configure the Widget for the production environment

That's it! You're now ready to accept fiat-to-crypto payments natively in your app.

– Payment Off Ramp

Fiat Off Ramp: Token to Fiat - Payment Methods, Fees & Other Details

Global Payout Infrastructure

That same turnkey solution also provides your users a reliable method of getting the most for their Virtual Financial Assets (VFAs) and only had to include a few lines of code and the Everest Payments Library to accomplish that.

We provide a hosted redirect model, where through a redirect to our widget your users complete their transaction and are then returned into your website or app experience.

The Everest Payments Library provides your users with the ability to sell cryptocurrency and receive their proceeds into their bank or debit card account. The sales process is quick and simple to accomplish. After a brief enrollment, the user connects their bank account or debit card, sends in their VFA, and when receipt confirmed are sent their funds.

Off Ramp Widget Screens	-

Before You Go Live:

– Finish your Partnership Agreement with Everest and complete KYC

– Create your production Everest account

– Configure the Widget for the production environment

– Token Swapping

Crypto Swaps

Some users just want a secure, reliable method of trading or swapping their token, the Everest Payments Library provides these capabilities as well. Swapping provides access to some of the largest liquidity pools to enable the user to send their token in, and to quickly and inexpensively receive another one back.

With more than 200 tokens on offer, Swap with the Payments Library gives your users the ability to get the tokens they want with super low fees. Unlike other offerings, Swap with the Payments Library does away with the perils of AMM-powered systems like front running, slippage, and liquidity concerns.

| Swap Widget Screens| - | | :--- | ---: | | | |

Before You Go Live:

– Finish your Partnership Agreement with Everest and complete KYC

– Create your production Everest account

– Configure the Widget for the production environment

Limits, Supported Currencies and Countries

Supported KYC Countries Fiat Currencies & Countries

Minimum Transaction Size for the Everest Payments Library is €50 or equivalent

Currencies Supported: Euro and USD

Countries Supported: Austria, Belgium, Cyprus, Estonia, Finland, France, Germany, Greece, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Monaco, Netherlands, Portugal, Slovakia, Slovenia, Spain, United States.

The Everest Payments Library Package

How To Incorporate Payments Library With Your Code

First, install the library package

npm install --save everest-sdk 

Or download from NPM

The following options can be provided to the library package to change it's behavior:

env {sandbox, production}
appKey
widgetWidth
widgetHeight

How to embed the Payments Library

import React from 'react'
import everestSDK from 'everest-sdk'

const App = () => {
    const options = {
        appKey: "__PROVIDED_BY_EVEREST__",
        widgetWidth: "600px",
        widgetHeight: "700px"
    };
    return <button onClick={() => everestSDK.initialize(options)}>Click Me</button>
};

export default App

– Admin Console

Inspect Your User's Transactions

Organizations that deploy the Everest Payments Widget have the option to request access to the Everest Admin Console which provides information about past transactions and those in process. If you have end-user technical support personnel, this is the portal they would visit to diagnose a customer issue.

Image	Description
	Your customers interact with the Payments Library embedded into your Dapp, Website or App. They can Buy and Sell a variety of Virtual Financial Assets, or tokens, using debit card or bank transactions.
	Your customer care workers interact with the Payment Dashboard to verify the status of past and ongoing transactions. Searches for individual transactions or wallet addresses allow employees to quickly locate an individual or transaction.
	The entire transaction is available to the customer care worker. Transaction Status, Timestamp, Type, Exchange, Network, Fiat Amount, Token Amount, Everest Fee, Network Fee, Wallet Address, funding source, Risk Details and more are available if needed.

Everest Payments API v4

Overview

The Everest Payments API v4 provides flexible integration options for processing card payments. Choose the integration method that best fits your technical requirements and compliance capabilities.

Available Integration Methods:

• Hosted Payment Integration - Fastest to integrate, minimal PCI compliance requirements
• Integrated Payment with 3DS - Seamless user experience, Everest handles authentication
• Advanced Payment Integration - Full control with your own 3DS provider

Choosing Your Integration Method

Environments

Testing: - https://integration-everest-api.dev.identitynetwork.io

Production: - https://api.prod.identitynetwork.io

Common Request Headers

All payment requests require the following HTTP headers:

• X-Api-Key: Your unique API key for authentication
• Content-Type: Must be set to application/json

HMAC Authorization

All Everest Payments API v4 requests must be authenticated with an HMAC-SHA256 signature. This section defines the exact headers to send, how to construct the signing string, and what the server validates.

1) Required headers

• Authorization: hmac username="<org>", algorithm="hmac-sha256", headers="request-line host x-date", signature="<base64>"
• x-date: RFC 1123 UTC timestamp, e.g., Tue, 04 Nov 2025 12:34:56 GMT
• X-Api-Key: Your Everest API key
• Content-Type: application/json

Optional (recommended hardening): - x-nonce: Unique, single-use value per request (if enabled by your integration)

2) Canonical signing string (exact)

${METHOD} ${PATH_AND_QUERY} HTTP/1.1\nhost: ${HOST}\nx-date: ${RFC_1123_DATE}

• METHOD: Uppercase HTTP method (GET, POST, ...)
• PATH_AND_QUERY: Original path plus query, no scheme or host (e.g., /v4/payments/?q=1)
• HOST: Host the client is calling. Behind proxies/CDNs, align on either Host or x-forwarded-host and keep it consistent across client and server.
• RFC_1123_DATE: Exactly the value sent in x-date

Example values: - METHOD: POST - PATH_AND_QUERY: /v4/payments/ - HOST: integration-everest-api.dev.identitynetwork.io - x-date: Tue, 04 Nov 2025 12:34:56 GMT

The HMAC is computed as base64( HMAC-SHA256( signing_string, <shared_secret_for_username> ) ).

3) Example request (test environment)

curl --location 'https://integration-everest-api.dev.identitynetwork.io/v4/payments/' \
  --header 'X-Api-Key: <your_api_key>' \
  --header 'Content-Type: application/json' \
  --header 'x-date: Tue, 04 Nov 2025 12:34:56 GMT' \
  --header 'Authorization: hmac username="INF", algorithm="hmac-sha256", headers="request-line host x-date", signature="<base64_signature>"' \
  --data '{
    "ccy": "EUR",
    "transaction_type": "CHECKOUT",
    "amount": 10000,
    "uuid": "0f5cf03b-2a42-37fa-b3d3-8790347d1598"
  }'

4) Server-side verification (what the server enforces)

1. Authorization header is present and follows the hmac scheme; x-date is present.
2. algorithm is hmac-sha256; headers is exactly request-line host x-date (or includes x-nonce if enabled).
3. x-date is a valid RFC 1123 timestamp within an allowed skew window (recommended ±5 minutes).
4. username is recognized; the shared secret is resolved from a secure store.
5. Rebuild the canonical signing string using the incoming request and timestamp.
6. Compute HMAC-SHA256 with the shared secret; Base64-encode.
7. Compare to the provided signature using constant-time equality. On any mismatch or policy violation, respond 401 Unauthorized (optionally include WWW-Authenticate: hmac).

5) Common errors and how to fix

• Signature mismatch → Ensure the signing string matches exactly (method, path+query, host, newline characters, x-date).
• Stale/invalid x-date → Check system time sync (use NTP) and RFC 1123 format; keep within ±5 minutes.
• Wrong host value → Sign the effective host your server verifies. If behind a proxy/CDN, standardize on x-forwarded-host (documented) and use the same on both sides.
• Path normalization issues → Sign the original path and query as sent; avoid rewriting or double-encoding.
• Base64/HMAC mistakes → Use HMAC-SHA256 (not SHA1 or SHA256 digest), Base64-encode the raw HMAC bytes (not hex).

6) Security recommendations

• Require TLS for all requests; perform HMAC verification before any processing.
• Optionally add x-nonce to the signed headers and reject nonce reuse within the skew window to prevent replay.
• Pin the expected host; reject requests for unexpected domains.
• Log authentication failures with reason codes for operational insight (without logging secrets).

7) Quick checklist for clients

• Generate x-date in RFC 1123 UTC.
• Build the canonical string exactly as specified.
• Compute base64(HMAC-SHA256(string, shared_secret)).
• Send Authorization with username, algorithm, headers, signature.
• Keep clocks synchronized; rotate secrets securely.

Hosted Payment Integration

The Hosted Payment Integration (CHECKOUT flow) provides the fastest path to accepting payments with minimal PCI compliance requirements. Your users are redirected to a secure, hosted checkout page where they enter their payment details and complete 3DS authentication.

Key Benefits: - Minimal PCI compliance burden (you never handle card data) - Fastest integration - just POST and redirect - Payment provider handles all authentication - Reduced liability and security overhead

Use Cases: - E-commerce checkouts - Subscription sign-ups - Quick payment acceptance without custom UX

Payment Request

Endpoint:

POST https://integration-everest-api.dev.identitynetwork.io/v4/payments/

Request Example:

curl --location 'https://integration-everest-api.dev.identitynetwork.io/v4/payments/' \
--header 'X-Api-Key: kfWIcvhS6qAdS4p' \
--header 'Content-Type: application/json' \
--data '{
    "ccy": "EUR",
    "transaction_type": "CHECKOUT",
    "amount": 10000,
    "uuid": "0f5cf03b-2a42-37fa-b3d3-8790347d1598"
}'

Request Parameters:

Success Response:

{
    "success": true,
    "code": {
        "code": 1,
        "message": "SUCCESS"
    },
    "data": {
        "order": {
            "order_id": "8026ecde-f2f7-4e04-9268-1e7d2de96fc7",
            "provider_token": "7FABC851179948072998EBA5627B7187.uat01-vm-tx03"
        },
        "user": {
            "uuid": "0f5cf03b-2a42-37fa-b3d3-8790347d1598"
        },
        "checkout_id": "7FABC851179948072998EBA5627B7187.uat01-vm-tx03"
    }
}

Response Fields:

Next Steps:

After receiving the successful response:

1. Redirect your user to the payment provider's checkout page using the checkout_id
2. User completes payment and 3DS authentication on hosted page
3. User is redirected back to your application
4. Check payment status using the Payment Status endpoint

Integrated Payment with 3DS

The Integrated Payment method allows you to collect card details in your application while Everest manages the 3DS authentication process. This provides a seamless user experience while reducing your 3DS integration complexity.

Key Benefits: - Control the payment form UX - Everest handles 3DS authentication complexity - Seamless redirect or iframe for 3DS challenges - Single integration point

Use Cases: - Custom branded checkout experiences - Mobile applications requiring native card entry - When you want control over UX but not 3DS infrastructure

Payment Request

Endpoint:

POST https://integration-everest-api.dev.identitynetwork.io/v4/payments/

Request Example:

curl --location 'https://integration-everest-api.dev.identitynetwork.io/v4/payments/' \
--header 'X-Api-Key: kfWIcvhS6qAdS4p' \
--header 'Content-Type: application/json' \
--data '{
    "ccy": "EUR",
    "transaction_type": "CARD",
    "amount": 3000,
    "uuid": "0f5cf03b-2a42-37fa-b3d3-8790347d1598",
    "card": {
        "holderName": "Sarah Wilson",
        "number": "4000000000000044",
        "expiry": "03/27",
        "cvv": "321"
    },
    "threeDs": {
        "type": "INTERNAL",
        "redirectUrl": "https://wallet.everest.org"
    }
}'

Request Parameters:

Card Object:

ThreeDs Object (Internal):

PI Object (Personal Information):

Address Object:

Success Response:

{
    "success": true,
    "code": {
        "code": 1,
        "message": "SUCCESS"
    },
    "data": {
        "order": {
            "order_id": "298f1001-6710-4c04-ad16-8b5ca3c21713",
            "provider_token": "8ac7a49f99c5e88a0199c83792e32718"
        },
        "user": {
            "uuid": "0f5cf03b-2a42-37fa-b3d3-8790347d1598"
        },
        "payment_status": "pending_3ds",
        "payment_id": "8ac7a49f99c5e88a0199c83792e32718",
        "requires_redirect": true,
        "redirect_url": "https://test.oppwa.com/connectors/asyncresponse_simulator;jsessionid=2DFA3257D88191481DA0183292E610AE.uat01-vm-con02?asyncsource=ACI_3DS_2&type=methodRedirect&cdkForward=true&ndcid=8ac7a4ca98f560650198f60fdbc40174_bbc191b0d6e447e1ba659b80edc770c6"
    }
}

Response Fields:

3DS Authentication Flow:

1. Submit payment request with card details and threeDs.type: "INTERNAL"
2. Receive response with requires_redirect: true and redirect_url or provider_token
3. Render Payment Widget using the provider_token as checkoutId
4. User completes 3DS authentication in the widget
5. User redirected to your action URL specified in the form
6. Check payment status using Payment Status endpoint

2. Render the Payment Widget

When using threeDs.type: "INTERNAL" and receiving a provider_token in the response, you need to render the payment widget for 3DS authentication.

Widget Environments: - Test: https://eu-test.oppwa.com/v1/ - Production: https://eu-prod.oppwa.com/v1/

Add the Payment Script

Include the script below on your checkout page:

<script
 src="https://eu-test.oppwa.com/v1/paymentWidgets.js?checkoutId={checkoutId}"
 integrity="{integrity}"
 crossorigin="anonymous">
</script>

Parameters: - checkoutId: Value from provider_token - integrity: Integrity hash (if provided) - crossorigin: Use "anonymous" or your domain

Add the Payment Form

<form
 action="{shopperResultUrl}"
 class="paymentWidgets"
 data-brands="VISA MASTER">
</form>

Attributes: - action: Redirect URL after payment - data-brands: Payment brands to display (e.g., VISA MASTER)

Example – Test Environment

<script
 src="https://eu-test.oppwa.com/v1/paymentWidgets.js?checkoutId=20F71F776AE3CEF811FBA4C4F2B31271.uat01-vm-tx01"
 integrity="sha384-KnYRC1jbE3C9SMGbJ5eU2Gx+AM9PCaApfqS6lk8MpPlvk9jIii4PFu297dPu4wcy"
 crossorigin="https://example.com">
</script>

<form
 action="https://myshop.example.com/paid"
 class="paymentWidgets"
 data-brands="VISA MASTER">
</form>

Example – Production Environment

<script
 src="https://eu-prod.oppwa.com/v1/paymentWidgets.js?checkoutId=20F71F776AE3CEF811FBA4C4F2B31271.prod01-vm-tx01"
 integrity="sha384-abc123xyz..."
 crossorigin="https://example.com">
</script>

<form
 action="https://myshop.example.com/paid"
 class="paymentWidgets"
 data-brands="VISA MASTER">
</form>

3. Notes & Best Practices

• Checkout Expiry: Each checkout ID expires after 30 minutes. After expiration, request a new one.

Advanced Payment Integration

The Advanced Payment Integration is designed for organizations that already have their own 3DS authentication provider and want full control over the payment flow. You handle both card collection and 3DS authentication, then send the complete authentication results to Everest.

Key Benefits: - Complete control over user experience - Use your existing 3DS provider - Full flexibility in authentication flow - Optimal for complex payment workflows

Use Cases: - Organizations with existing 3DS infrastructure - Complex multi-step checkout flows - Custom authentication requirements - Legacy system integrations

⚠️ Requirements: - 3DS provider relationship and integration - Technical expertise in 3DS protocols

Payment Request

Endpoint:

POST https://integration-everest-api.dev.identitynetwork.io/v4/payments/

Request Example:

curl --location 'https://integration-everest-api.dev.identitynetwork.io/v4/payments/' \
--header 'X-Api-Key: kfWIcvhS6qAdS4p' \
--header 'Content-Type: application/json' \
--data '{
    "ccy": "EUR",
    "transaction_type": "CARD",
    "amount": 10002,
    "uuid": "0f5cf03b-2a42-37fa-b3d3-8790347d1598",
    "card": {
        "holderName": "Sarah Wilson",
        "number": "4000000000000044",
        "expiry": "03/27",
        "cvv": "321"
    },
    "threeDs": {
        "type": "EXTERNAL",
        "cavv": "AAABCIEicAAAAAACEVIRWCCCCCA=",
        "eci": "06",
        "dsTransId": "b23c4d5e-6789-abcd-ef01-234567890bcd",
        "threeDResult": "A",
        "threeDSecureVersion": "2.1.0"
    }
}'

Request Parameters:

Card Object:

ThreeDs Object (External):

3DS Result Codes:

Success Response:

{
    "success": true,
    "code": {
        "code": 1,
        "message": "SUCCESS"
    },
    "data": {
        "order": {
            "order_id": "76c6fef8-6de6-4c52-bdcd-a0994e0784bb",
            "provider_token": "8ac7a49f99c5e88a0199c836b54e227e"
        },
        "user": {
            "uuid": "0f5cf03b-2a42-37fa-b3d3-8790347d1598"
        },
        "payment_id": "8ac7a49f99c5e88a0199c836b54e227e"
    }
}

Response Fields:

External 3DS Flow:

1. Collect card details in your application
2. Authenticate with your 3DS provider and obtain authentication results
3. Submit payment request with card data and 3DS results
4. Receive payment confirmation or error
5. Check payment status if needed using Payment Status endpoint

Get Payment Status

Use this endpoint to check the current status of any payment transaction. This is essential for: - Verifying payment completion after 3DS redirects - Polling for async payment updates - Customer support inquiries - Reconciliation processes

Status Request

Endpoint:

GET https://integration-everest-api.dev.identitynetwork.io/v4/payments/{payment_id}/status

Request Example:

curl --location 'https://integration-everest-api.dev.identitynetwork.io/v4/payments/8ac7a49f99c5e88a0199c836b54e227e/status' \
--header 'X-Api-Key: kfWIcvhS6qAdS4p'

URL Parameters:

Success Response:

{
    "success": true,
    "code": {
        "code": 1,
        "message": "SUCCESS"
    },
    "data": {
        "payment_id": "8ac7a49f99c5e88a0199c836b54e227e",
        "order_id": "76c6fef8-6de6-4c52-bdcd-a0994e0784bb",
        "status": "COMPLETED",
        "amount": 10002,
        "ccy": "EUR",
        "created_at": "2024-01-15T10:30:00Z",
        "updated_at": "2024-01-15T10:31:45Z"
    }
}

Payment Status Values:

Webhook Configuration

Webhooks allow you to receive real-time notifications about payment events and status changes. This ensures your system stays synchronized with payment outcomes without polling.

Setting Up Webhooks

Important: Webhook configuration must be set up by the Everest team. You cannot configure webhooks manually at this time.

To configure webhooks for your integration:

1. Contact Everest at developer@everest.org with:

   • Your API key
   • Your webhook endpoint URL (must be HTTPS)
   • Events you want to subscribe to (e.g., payment completion, failures)
   • Environment (test or production)

2. Provide a secure HTTPS endpoint that can:

   • Accept POST requests
   • Return 2xx status codes for successful receipt
   • Handle duplicate notifications idempotently

3. Everest will configure your webhook and provide:

   • Webhook secret for signature verification
   • List of configured events
   • Test webhook functionality

Webhook Payload Format

{
  "order_id": "<string>",             // Unique Everest transaction identifier
  "status": "<string>",               // One of: COMPLETED, PENDING, DECLINED, ERROR, etc.
  "amount": <integer>,                // Amount in minor units (e.g., 2113 means €21.13)
  "meta": <object>,                   // Original meta attributes (JSON)
  "payment_error": {                  // Populated only if status == ERROR or DECLINED
    "code": "<string>",               // See "PaymentError Codes" below
    "description": "<string>"
  }
}

Webhook Security

Signature Verification (Coming Soon)

Everest will provide a webhook secret for verifying webhook authenticity. Until then:

• Whitelist Everest IPs (provided during setup)
• Use HTTPS only for your webhook endpoint
• Validate webhook data by checking payment status via API

Webhook Response Requirements

Your endpoint must:

• Return quickly (within 5 seconds)
• Return 2xx status for successful receipt
• Handle retries - Everest will retry failed webhooks with exponential backoff
• Be idempotent - Handle duplicate notifications gracefully

Example Response: ```http HTTP/1.1 200 OK Content-Type: application/json

{ "received": true } ```

Testing Webhooks

Once configured by Everest:

1. Test endpoint using the test environment
2. Verify events are received correctly
3. Test error handling by returning non-2xx status
4. Validate idempotency with duplicate events

Error Codes - Everest Payments API v4

The following error codes may be returned by the Everest Payments API v4. All error responses follow this format:

{
    "success": false,
    "code": {
        "code": 1006,
        "message": "UNPROCESSABLE_ENTITY"
    },
    "data": {
        "validation_errors": [...]  // Optional field-level details
    }
}

1. Request Validation Errors

2. Fee Calculation Errors

3. User Onboarding Validation Errors

When UUID is provided but user not found:

4. Gateway Card/Authentication Errors

5. Gateway Transaction Errors

6. Gateway Fraud/Risk Errors

7. Gateway Provider Specific Errors

8. Gateway System Errors

9. Gateway Validation Errors

10. Payment Processing Errors

11. System Errors

Everest Payments Direct API (Legacy)

Overview

Let's get started! Your available resources include:

• Overview - Steps to get setup and developing quickly

• Integration Checklist - What you will need to accomplish to integrate payments via the API

• Implementation Documentation - What you need to know to include the Everest functionality in your app

The Everest Payments Direct API enables you to process card numbers in your products and services through Everest and Paysafe.

The Everest APIs allow authorized partner organizations to automate various tasks related to handling card payments. This includes being able to initiate transactions of various kinds, and exercise other Everest Platform functionality.

This diagram describes the flow:

|

Environments

Testing:

• https://integration-everest-api.dev.identitynetwork.io
• https://api.test.paysafe.com/paymenthub/v1/payments

Production:

• https://api.prod.identitynetwork.io
• https://api.prod.paysafe.com/paymenthub/v1/payments

API Request

All card payment acquisition requests are sent via HTTP POST to the following endpoint:

POST https://integration-everest-api.dev.identitynetwork.io/v4/accounts/merchants

Required Headers

The following HTTP headers are mandatory for all requests:

• x-api-key: Your unique API key for authentication.
  • Example: kfWIcvhS6qAdS4p
• Content-Type: Must always be set to application/json.

Request Body

The request body must be a JSON object with the structure defined below. Fields marked "(required)" are mandatory.

{
  "ccy": "<string, required>",
  "uuid": "<string, optional>",
  "pi": {
    "dob": "<string, required if pi>",
    "email": "<string, required if pi>",
    "fname": "<string, required if pi>",
    "gender": "<string, required if pi>",
    "lname": "<string, required if pi>",
    "phone": "<string, required if pi>"
  },
  "address": {
    "street": "<string, required if pi>",
    "secondary_street": "<string, optional>",
    "city": "<string, required if pi>",
    "state": "<string, required if pi>",
    "postcode": "<string, required if pi>",
    "country": "<string, required if pi>"
  },
  "amount": <integer, required>,
  "meta": {
    "ext_trx_id": "<string, required>"
  }
}

Field Explanations

• ccy (required):
  Three-letter currency code, conforming to ISO 4217.

  • Example: "EUR"

• uuid (optional):
  The unique user identifier assigned when a member was first onboarded. Once a user is onboarded, subsequent purchase requests need only include this uuid. If you do not have a stored user UUID (e.g., this is a new user flow), you may omit this field.

• pi (Personal Information):
  Contains basic personal data for a new user. If any field in pi is provided, the address object must also be included. When onboarding a first-time user, populate these fields; for returning users (providing uuid), pi can be omitted.

  • dob (required if pi is present):
    Date of birth, in YYYY-MM-DD format.
  • email (required if pi is present):
    Member’s email address.
  • fname (required if pi is present):
    Member’s first name.
  • gender (required if pi is present):
    Member’s gender, either "M" or "F".
  • lname (required if pi is present):
    Member’s last name.
  • phone (required if pi is present):
    Member’s phone number in E.164 format (e.g., "+44207123456").

• address (required when pi is provided):
  The residential address for a new user. If you supply any pi fields, include address as well.

  • street (required if pi is present):
    Primary street address.
  • secondary_street (optional):
    Secondary address line (e.g., apartment or suite number).
  • city (required if pi is present):
    City of residence.
  • state (required if pi is present):
    State or province.
  • postcode (required if pi is present):
    Postal code.
  • country (required if pi is present):
    Country code, conforming to ISO 3166-1 alpha-3 (e.g., "MLT").

• amount (required):
  Integer representing the amount in minor currency units.

  • Examples:
    
  • 2113 → €21.13
    
  • 1099 → $10.99

• meta (required for CARD flow):
  Contains metadata used internally by Everest.

  • ext_trx_id (required):
    A unique string identifier generated by your system when the user enrolled or authenticated their card. Everest uses this ID to fetch stored card details (including 3DS data) without exposing sensitive payment information.

Example Request

curl --location 'https://integration-everest-api.dev.identitynetwork.io/v4/accounts/merchants' \
  --header 'x-api-key: kfWIcvhS6qAdS4p' \
  --header 'Content-Type: application/json' \
  --data-raw '{
    "uuid": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
    "pi": {
      "dob": "1981-01-20",
      "email": "johndoe@gmail.com",
      "fname": "John",
      "gender": "M",
      "lname": "Doe",
      "phone": "+44207123456"
    },
    "address": {
      "street": "42 Baker Street",
      "secondary_street": "Apt 3B",
      "city": "London",
      "state": "ENG",
      "postcode": "NW1 6XE",
      "country": "GBR"
    },
    "ccy": "EUR",
    "amount": 2113,
    "meta": {
      "ext_trx_id": "test-everest"
    }
}'

In this example:

• amount: 2113 represents €21.13.
• ext_trx_id: "test-everest" triggers Everest's built-in mock card lookup behaviorsection 8).

Sample Success Response

A successful request will return an HTTP 200 OK status code with a JSON body similar to this:

{
    "success": true,
    "code": {
        "code": 1,
        "message": "SUCCESS"
    },
    "data": {
        "user": {
            "uuid": "c8325cb1-86b3-47c2-b54e-306d694674fe"
        },
        "order": {
            "order_id": "4339f0dc-9e24-4e8e-8b57-a84162285f32"
        }
    }
}

Fetch Card Information API

Retrieves stored card and 3DS authentication data using a previously issued ext_trx_id.

Endpoint

• Http Method: GET
• URL Base: https://<your-merchant-gateway-domain>/?id=<ext_trx_id>
• Query Parameter:
  • id (required): The ext_trx_id string that was generated when the card was enrolled/authenticated.

Required Headers

• Authorization (required)

  • Basic Auth header containing your gateway credentials.
    
  • Example: Authorization: Basic <base64(username:password)>

• Content-Type (required)

  • Must be application/json

Success Response (HTTP 200)

On success, returns a JSON object with both card details and 3DS data.

{
  "success": true,
  "card": {
    "holderName": "<string>",       // Cardholder’s full name
    "number": "<string>",           // Full Primary Account Number (PAN), e.g. "4907639999909022"
    "expiry": "<string>",           // Expiry date in "MM/YY" format, e.g. "07/28"
    "cvv": "<string>"               // CVV code, e.g. "123"
  },
  "threeD": {
    "cavv": "<string>",                  // Cardholder Authentication Verification Value (base64-encoded)
    "eci": "<string>",                   // Electronic Commerce Indicator, e.g. "05"
    "dsTransId": "<string>",             // Directory Server Transaction ID (UUID)
    "threeDResult": "<string>",          // "Y" if 3DS succeeded; other EMV-defined codes if not
    "threeDSecureVersion": "<string>"    // 3DS protocol version, e.g. "2.2.0"
  }
}

Field Explanations for Fetch Card Information Response

• success (boolean)
  Indicates whether the card lookup succeeded.

  • true: Card and 3DS data were found and returned.
    
  • false: Card lookup failed (in that case, generally an error response is returned instead).

• card (object)
  Contains the stored payment card details.

  • holderName (string)
    The full name of the cardholder as stored in the vault.
    
  • Example: "John Doe"
  • number (string)
    The full Primary Account Number (PAN) of the card.
    
  • Example: "4907639999909022"
  • expiry (string)
    Expiration date in MM/YY format.
    
  • Example: "07/28"
  • cvv (string)
    The 3- or 4-digit CVV/CVC security code.
    
  • Example: "123"

• threeD (object)
  Contains 3DS (Three-Domain Secure) authentication data.

  • cavv (string)
    Cardholder Authentication Verification Value (base64-encoded). Used by the payment processor to verify 3DS authentication.
    
  • Example: "ABABAhCTOAAAALc9V4BIdYBCQoU="
  • eci (string)
    Electronic Commerce Indicator (two-digit code). Indicates the outcome of the 3DS authentication.
    
  • Example: "05"
  • dsTransId (string)
    Directory Server Transaction ID (UUID). Unique identifier for the 3DS session with the directory server.
    
  • Example: "0e65ede4-a74b-492a-b756-7e9874802204"
  • threeDResult (string)
    Three-Domain Secure result code.
    
  • "Y": 3DS authentication succeeded.
    
  • Other EMV-specified codes (e.g., "N", "U") indicate failure or unavailable.
    
  • threeDSecureVersion (string)
    Version of the 3DS protocol used during authentication.
    
  • Example: "2.2.0"

Webhook Integration

Important: Webhook configuration must be set up by the Everest team. You cannot configure webhooks manually at this time. Contact developer@everest.org with your webhook endpoint URL and requirements.

As part of the integration, you must supply Everest with a publicly accessible HTTPS endpoint (webhook URL). Everest will send an HTTP POST to this endpoint whenever a transaction status changes.

• Request Method: POST
• Content-Type: application/json
• URL: Your provided webhook URL (HTTPS)
  

Sample Response

{
  "order_id": "<string>",             // Unique Everest transaction identifier
  "status": "<string>",               // One of: COMPLETED, PENDING, DECLINED, ERROR, etc.
  "amount": <integer>,                // Amount in minor units (e.g., 2113 means €21.13)
  "meta": <object>,                   // Original meta attributes (JSON)
  "payment_error": {                  // Populated only if status == ERROR or DECLINED
    "code": "<string>",               // See “PaymentError Codes” below
    "description": "<string>"
  }
}

Status Meanings

• COMPLETED: The transaction was fully approved, and funds will settle.
• PENDING: The authorization is held, awaiting final settlement.
• DECLINED: The card was declined (e.g., insufficient funds, risk decline by issuer).
• ERROR: An unexpected issue occurred during processing.

Delivery Semantics

• Everest issues a POST to your webhook URL as soon as the transaction is finalized or updated.
• Your endpoint must respond with a 2xx HTTP status code to acknowledge successful receipt.
• If Everest receives a non-2xx response or a network error, it will retry delivery using exponential backoff (up to a configurable retry limit).
• After exhausting retries, Everest logs the failure and surfaces an alert for manual intervention.

Webhook Payment Error Codes

Everest Identity Oracle

Chainlink Access to Everest Oracle

Everest identity information and claims are available to be used over the Chainlink oracle network.

Everest Identity Services in 50 Words: Everest provides a full identity stack to users and partners which enables consumers to self-enroll through a webpage to prove various aspects of their identity to others. From the most foundational human & unique status, to a complete financial service grade Know Your Customer processes, Everest solves your real world identity issues.

Everest & Chainlink Direct Request: Through the Chainlink Direct Request mechanism, organizations can inexpensively query Everest to learn the Human & Unique or KYCed status of an ERC-20 wallet, gaining valuable insight into how to handle the transactions from that wallet address.

Smart contract developers will have a full Web 3.0 infrastructure stack including blockchains for on-chain logic and state changes, Chainlink oracles for off-chain communication and computation, and Everest for unique human identity, account creation/verification, KYC/AML, and KYB organisational registration.

Additional information can be found in the Business Case and Developer "How To" guides below:

Business Case - Why to use the Everest Identity Oracle.

Developer "How To" - Set up Everest Identity Oracle access.

Everest EverWallet

The Everest EverWallet is flexible wallet software framework designed to include other wallet technologies and provide a unified solution to build your app or dapp on top of. The EverWallet allows users to conduct financial transactions, sign Web3 transactions, interact with multiple networks all through the same interface.

Digital wallet, fiat wallet, crypto wallet, identity wallet - EverWallet can support your wallet needs from simple account provisioning to full financial services KYC and everything in between. Endowed with the ability to hold fiat currencies, cryptocurrencies, identity claims, documents, and more, EverWallet is a common component for Everest Platform services and serves as the storage location.

Your users will be able to spend, save, lend and spend in fiat and crypto, store documents, medical records and sensitive data locked with your biometry – never lose your keys or access again.

EverWallets are able to hold cryptocurrency and fiat balances (for the supported tokens and currencies), send a receive tokens (from those integrated networks), and support both token trades and token swaps. Contact Everest to get current information on supported geographies, tokens and currencies.

EverWallet is able to be white labeled and customized for your exact purposes. Need to pre-screen qualified financial services clients, we can create an EverWallet for that. Want to issue reward tokens for the first 1,000 users who sign up for your new service, we can create an EverWallet for that. Want to use the Everest financial-services-approved Know Your Customer (KYC) utility to onboard new clients, we can create an EverWallet for that purpose too.

The EverWallet framework enables developers to create both custodial and non-custodial solutions for their specific needs, while having the ability to leverage those tools provided by the Everest Platform.

Institutional Compliance mechanisms

The EverWallet enables you to create custom mechanisms to enforce your specific procedures and specific workflows to record approvals and track authorization to spend funds controlled by the wallet platform. Everything from simple title-driven constraints like "requires Director approval" to complex structures like tiered requirements of 2 signatures to spend over €1,0000 and 3 signatures over €100,000. Even down to direct budget controls being put in place requiring a specific signatory required for spending from specific wallets. Institutions can control independently the access users have to EverWallets, and can add and remove access without divulging the keys or compromising direct controls.

Everest Identity Wallet Library (New)

Overview

Everest is introducing another innovation for digital identity - the Everest Identity Wallet Library.

Everest is delivering an easy to deploy, easy to use online identity service as a base service for you to add to other services. From the point of view of a consumer wishing to conduct an online activity which requires certain aspects of identity to be proven, there needs to be a service which is simple and easy to complete. From the point of view of the developer delivering the above solution, the focus shifts to the ability to easily integrate and leverage the identity service.

The goal of the "Identity Wallet" is to empower 1000s of developers, dApps, wallets to easily (integrate in under one day with minimal to no support, and be self-service) prove human, deduplicated, name, DOB, KYC status, residency, and similar attributes; by allowing users to attach claims to various EverWallets, connected wallets and linked wallets, a level of pseudonymity is achieved.

What is required for integration:

• Everest SDK NPM package and Everest SDK Key / Secret

• Integration of Everest SDK NPM package into Dapp / Site - stand alone, or part of a workflow

• Integration testing to verify that the NPM package is properly implemented and is configured with the appropriate SDK Keys for connectivity

• Integration Certification video conference with Everest personnel to verify that NPM package is configured correctly

Integration Checklist

To help out during the integration process, we've created this checklist for you to follow. This is the same checklist we will be using to ensure you have addressed all items before being granted access to the Production environment, so please be sure to complete it. Click here for a downloadable version of the checklist.

Securing the session with the session token

To secure each session there is a specific sequence that we use which is detailed in the following diagram. First you receive a temp_token, which is swapped for a public_token, which in turn is swapped for a long-lived access_token. This access_token is used for further transactions on this user's behalf.

The Identity Wallet Library flow begins with your user invoking the library, either as a stand-alone experience or as a component of a workflow. – Call /everest/token/create to create a ephemeral temp_token and pass it into your client at session start – Using the temp_token open the Identity Library and you will receive in the onSuccess callback the public_token – Call /everest/public_token/exchange to receive the long-lived access_token. – Store the access_token for future use by that user. You will end up with an array of access_tokens for your user base.

Implement the client side component

While you're integrating the Everest Identity Wallet Library client side component, make sure that:

• Your application is configured to authenticate and post data before calling the Everest NPM package.

• You implement the Error, Success and Exit callback functions.

• You Implement the client side component to handle links with an invalid or token_required status requiring a new password or a new API Key.

• You use the token.resources field to define which tokens are available in the client side code.

Identity Wallet Library Features

The Everest Identity Wallet Library allows you to quickly add additional identity verification statuses to your existing app or Website.

– find just the Human & Unique individuals in a set of wallet addresses – screen individuals by various traits – KYC individuals for security or financial services reasons – collect information from users to pre-qualify them

Try it now at https://verified.foundationnetwork.org.

– Human & Unique

Wallet Screening: Human & Unique - Voting, Access Control,

Manage your User Base

The Identity Wallet Library is a turnkey solution that makes it easy for your users to demonstrate they control a wallet address. Your customers get a fast and secure way to prove they are human, not a bot, and not a sock puppet, and you get the peace-of-mind of knowing your voting process has integrity.

We provide a hosted redirect model, where through a redirect to our widget your users complete their task and are then returned into your website or app experience.

Users sign up from any integrated website with their webcam taking a selfie and verifying their contact details. After a brief enrollment process, which confirms they control the Web3 address they are claiming, you are able to redirect them back to your workflow or website.

Before You Go Live:

– Finish your Partnership Agreement with Everest

– Create your production Everest account

– Configure the Widget for the production environment

That's it! You're now ready to identity services and processes natively into your app.

– Know-Your-Customer

Client Onboarding: Identity Verification - eKYC, Sanctions and List Screening, Compliance Checks

Onboard new clients with confidence after screening them with the Everest KYC process. This is the same process and procedure used by financial institutions worldwide to record, review, and approve prospective clients. Complete screening against Anti-Money-Laundering (AML), Counter-the-Funding-of-Terrorism (CFT), Financial Sanctions lists, and Politically-Exposed-Persons lists. Truly know who your prospective client is before you provide them with access or services.

That same turnkey solution also provides small organizations the ability to quickly and inexpensively verify the identity and suitability of a candidate. Do you want to be certain your new cashier has not been sanctioned by a financial authority for fraud, have them KYC through the Everest Identity Wallet Library.

We provide a hosted redirect model, where through a redirect to our widget your users complete their transaction and are then returned into your website or app experience.

The Everest Identity Wallet Library gives you a new identity toolkit for verification, screening, and access control. The enrollment process is quick and simple to accomplish. Only want Human & Unique wallets voting in your DAO's elections? Need to screen people for your new public offering? Need to KYC individuals for your financial services platform? The Everest Identity Wallet Library can solve your needs today.

Before You Go Live:

– Finish your Partnership Agreement with Everest

– Create your production Everest account

– Configure the Widget for the production environment

– Admin Console

Inspect Your Users Status

Organizations that deploy the Everest Identity Wallet have the option to request access to the Everest Admin Console which provides information about past transactions and those in process. Your end-user technical support personnel will use this portal diagnose a customer issue.

Image	Description
	Your customers interact with the Identity Wallet library embedded into your Dapp, Website or App. They can prove a variety of attestations or claims. Human & Unique status ensures your votes are fair, and portable Know-Your-Customer validation allows financial institutions to confidently interact with people.
	A user which has no relationship with this organization will show up like this. No, this wallet has not been seen by this organization, and No, this wallet has not been KYCed.
	A user which has been onboarded by your organization will show up as a positive "hit" when their wallet address is pasted into the search bar. Yes, this wallet has been seen by this organization.
	A user which has been KYCed by this organization will show up as Yes, seen by this organization before, and Yes, they succeeded in passing the KYC requirements.

Errors

The Everest API uses the following error codes: