--- updatedAt: 2026-09-15T07:23:46.000Z agentTools: projectIndex: https://docs.praxis.tech/llms.txt --- # Server to Server This integration approach, grants merchants maximum control by enabling direct communication between their backend and the payment gateway. # 1. S2S Integration Foundation To successfully integrate and transact using S2S, the following technical components are **mandatory**: * **Security Signature:** Every outgoing S2S request and incoming response must contain a security **signature** (e.g., via the `gt-authentication` header). This signature is vital for ensuring data integrity and verifying that the request/response originated from a trusted source. Refer **Authentication** for more details. * **Tokenization (Cards):** For transactions involving Credit cards or e-Wallets(APM), Praxis can accept data in the form of a `card_token`, `wallet_token`, or the direct unencrypted `card_data` , `wallet_data`. However, for PCI compliance and security, we strongly advise that data is never sent directly via S2S. Instead, card details should be captured securely (e.g., using the HPF SDK) and replaced with a non-sensitive token, which is then passed in the S2S request. Refer **Server to Server - Card** or **Server to Server - APM** APIs. * **Card Data Encryption:** If you must send raw card details directly rather than using a `card_token`, the specific fields (`card_number`, `card_exp`, `cvv`) must be encrypted individually using **AES-256-CBC** (outputting raw binary data) and then **Base64 encoded**. * **Key (32 bytes):** Your Merchant Secret Key, left-padded with zeros (`0`) to exactly 32 characters
(e.g., `MySecret` → `000000000000000000000000MySecret`). * **Initialization Vector (IV) (16 bytes):** The `timestamp` from your request body, left-padded with zeros (`0`) to exactly 16 characters (e.g., `1628062452` → `0000001628062452`). * **Implementation Logic:** ```text // 1. Pad the Key and IV padded_key = pad_left(merchant_secret, 32, '0') padded_iv = pad_left(request_timestamp, 16, '0') // 2. Encrypt each field (e.g., card_number, card_exp, cvv) individually. // Ensure the AES function returns raw binary data (like OPENSSL_RAW_DATA in PHP). raw_encrypted_field = aes_256_cbc_encrypt(field_value, padded_key, padded_iv) // 3. Base64 encode the raw encrypted result final_encrypted_field = base64_encode(raw_encrypted_field) ``` * **Response Handling:** Your server must be ready to receive and process **Asynchronous Notifications (Webhooks)** for final status updates, especially for flows involving external steps (3DS, EW Login). **Note:** The currency exchange rates are sourced from below. * **Crypto Compare** (Cryptocurrency): Updated every **15 minutes**. * **Open Exchange Rates** (FIAT Currency): Updated every **5 minutes**. *** # 2. Transaction Flow Below is a summary of the available Server-to-Server (S2S) transaction flows. ## Authorization(Card) When integrating Authorization transactions, please refer to the following sequence diagram which illustrates the communication flow. ```mermaid --- config: theme: dark --- sequenceDiagram actor User as Customer participant Merchant as Merchant participant Praxis participant Acquirer User ->> +Merchant: Performs checkout
and initiates payment Note right of Merchant: Step 1: S2S - Initiate `authorization` flow Merchant->>+Praxis: Invoke `/api/direct-process`
with `transaction_type=authorization` Praxis->>+Acquirer: Send required transaction details. Acquirer -->>-Praxis: Authorizes the transaction
and sends response. Praxis-->>-Merchant: Returns S2S synchronous response
with `transaction` and `session` details Merchant-->>User: Send authorization
acknowledgement Note right of Merchant: Step 2: S2S - Capture or Cancel `authorization` Merchant->>+Praxis: Initiate `/agent/manage-transaction`
with `intent=capture|cancel` the funds alloted. Praxis->>+Acquirer: Send required transaction details. Acquirer -->>-Praxis: Approves the transaction
and sends response. Praxis-->>-Merchant: Returns S2S synchronous response
with `transaction` and `session` details Merchant-->>User: Notify transaction
approved / rejected ``` *** ## Sale(Card/APM) Refer to this sequence diagram for Sale transactions, detailing the required steps for immediate processing and capture. ```mermaid --- config: theme: dark --- sequenceDiagram actor User as Customer participant Merchant as Merchant participant Praxis participant Acquirer User ->> +Merchant: Performs checkout
and initiates payment Note right of Merchant: Step 1: S2S - Initiate `sale` flow Merchant->>+Praxis: Invoke `/api/direct-process`
with `transaction_type=sale` Praxis->>Acquirer: Send required transaction details. Acquirer -->> Praxis: Approves the transaction
and sends response. Praxis-->>-Merchant: Returns S2S synchronous response
with `transaction` and `session` details Merchant-->>-User: Send approved
acknowledgement ``` *** ## Refund(Card/APM) Refer to this sequence diagram for Refund flow to refund an approved deposit transaction. **Note 1:** The transaction you are attempting to reference must be a previously **approved deposit**; this original transaction's identifier is required in the `reference_id` request parameter. **Note 2:** You must confirm that the **PSP** supports the **refund transaction type**; specifically, verify that the PSP allows **partial refunds** if the refund amount is less than the original deposit. **Note 3:** When issuing a refund via **Atlas** or **API**, the **refund transaction currency must match the processing currency of the original deposit**. Furthermore, using the Direct API's refund functionality **does not require PCI certification**, as no card data is transmitted through this resource.
```mermaid --- config: theme: dark --- sequenceDiagram actor User as Customer participant Merchant as Merchant participant Praxis participant Acquirer User <<->> Acquirer: Completed Deposit transaction Note over User,Acquirer: Pre Requisite: `authorization` or `sale` transaction is already completed
succesfully by the Customer User ->> +Merchant: Performs refund
payment Note right of Merchant: Step 1: S2S - Initiate `refund` flow Merchant->>+Praxis: Invoke `/direct/refund`
with `transaction_type=refund`
and `refernce_id`(previous deposit) Praxis->>Acquirer: Send required transaction details. Acquirer -->> Praxis: Approves the transaction
and sends response. Praxis-->>-Merchant: Returns S2S synchronous response
with `transaction` and `session` details Merchant-->>-User: Send refund
acknowledgement ``` *** ## Payout(Card/APM) Refer to this sequence diagram for Payout flow to send funds from your merchant account to the customer's card.
```mermaid --- config: theme: dark --- sequenceDiagram actor User as Customer participant Merchant as Merchant participant Praxis participant Acquirer User ->> +Merchant: Performs payout
request Note right of Merchant: Step 1: S2S - Initiate `payout` flow Merchant->>+Praxis: Invoke `/api/direct-process`
with `transaction_type=payout` Praxis->>Acquirer: Send required transaction details. Acquirer -->> Praxis: Returns approved or pending
status. Praxis-->>-Merchant: Returns S2S synchronous response
with `transaction` and `session` details Merchant-->>-User: Send approved
or pending
acknowledgement ```