Guides
Start typing to search…

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.
  • 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.

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.

---
config:
  theme: dark
---
sequenceDiagram
    actor User as Customer
    participant Merchant as Merchant
    participant Praxis
    participant Acquirer

    User ->> +Merchant: Performs checkout<br> and initiates payment

    Note right of Merchant: Step 1: S2S - Initiate `authorization` flow
    Merchant->>+Praxis: Invoke `/api/direct-process` <br> with `transaction_type=authorization`
    Praxis->>+Acquirer: Send required transaction details.
    Acquirer -->>-Praxis: Authorizes the transaction<br> and sends response.
    Praxis-->>-Merchant: Returns S2S synchronous response <br> with `transaction` and `session` details
    Merchant-->>User: Send authorization<br>acknowledgement

    Note right of Merchant: Step 2: S2S - Capture or Cancel `authorization`
    Merchant->>+Praxis: Initiate `/agent/manage-transaction`<br> with `intent=capture|cancel` the funds alloted.
    Praxis->>+Acquirer: Send required transaction details.
    Acquirer -->>-Praxis: Approves the transaction<br> and sends response.
    Praxis-->>-Merchant: Returns S2S synchronous response <br> with `transaction` and `session` details
    Merchant-->>User: Notify transaction<br> approved / rejected

Sale(Card/APM)

Refer to this sequence diagram for Sale transactions, detailing the required steps for immediate processing and capture.

---
config:
  theme: dark
---
sequenceDiagram
    actor User as Customer
    participant Merchant as Merchant
    participant Praxis
    participant Acquirer

    User ->> +Merchant: Performs checkout<br> and initiates payment

    Note right of Merchant: Step 1: S2S - Initiate `sale` flow
    Merchant->>+Praxis: Invoke `/api/direct-process` <br> with `transaction_type=sale`
    Praxis->>Acquirer: Send required transaction details.
    Acquirer -->> Praxis: Approves the transaction<br> and sends response.
    Praxis-->>-Merchant: Returns S2S synchronous response <br> with `transaction` and `session` details
    Merchant-->>-User: Send approved<br>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.


---
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<br> succesfully by the Customer



    User ->> +Merchant: Performs refund<br>payment

    Note right of Merchant: Step 1: S2S - Initiate `refund` flow
    Merchant->>+Praxis: Invoke `/direct/refund` <br> with `transaction_type=refund` <br> and `refernce_id`(previous deposit)
    Praxis->>Acquirer: Send required transaction details.
    Acquirer -->> Praxis: Approves the transaction<br> and sends response.
    Praxis-->>-Merchant: Returns S2S synchronous response <br> with `transaction` and `session` details
    Merchant-->>-User: Send refund<br>acknowledgement

Withdrawal-to-Payout(Card/APM)

Refer to this sequence diagram for Withdrawal-to-Payout flow to send funds from your merchant account to the customer's card.

📘

You can manage the withdrawal request using Complete or Cancel Withdrawal Request API or split the withdrawal request using Create Split Withdrawal Request API


---
config:
  theme: dark
---
sequenceDiagram
    actor User as Customer
    participant Merchant as Merchant
    participant Praxis
    participant Acquirer

    User ->> +Merchant: Performs withdrawal<br>request

    Note right of Merchant: Step 1: S2S - Initiate `payout` flow
    Merchant->>+Praxis: Invoke `/api/direct-process` <br> with `transaction_type=payout`
    Praxis->>Acquirer: Send required transaction details.
    Acquirer -->> Praxis: Returns approved or pending<br>status.
    Praxis-->>-Merchant: Returns S2S synchronous response <br> with `transaction` and `session` details
    Merchant-->>-User: Send approved<br> or pending<br>acknowledgement

    Note right of Merchant: Step 2: S2S - Initiate <br> `split-withdrawal-request` flow <br> if `pending`
    Merchant->>+Praxis: Invoke `/agent/split-withdrawal-request`
    Praxis->>Acquirer: Send required transaction details.
    Acquirer -->> Praxis: Returns response.
    Praxis-->>-Merchant: Returns S2S synchronous response <br> with `transaction` and `session` details
		Merchant-->> User: Notify with<br> approved or rejected<br> status    

    Note right of Merchant: Step 3: S2S - Initiate <br>`manage-withdrawal-request` flow <br> if `pending`
    Merchant->>+Praxis: Invoke `/agent/manage-withdrawal-request`
    Praxis->>Acquirer: Send required transaction details.
    Acquirer -->> Praxis: Returns response.
    Praxis-->>-Merchant: Returns S2S synchronous response <br> with `transaction` and `session` details
    Merchant-->> User: Notify with<br> approved or rejected<br> status

Updated about 1 month ago