DOCSEARCHbyAlgolia
Submit Docs

Rafinita Payment Platform Documentation

website·Indexed 31 days ago

https://docs.rafinita.com/checkout_integration

API documentation for the Rafinita Payment Platform, covering S2S card and APM requests, checkout operations, and transaction management. Includes endpoints for Sale, Capture, Void, Refund, and Creditvoid, as well as recurring payment scheduling, transaction status retrieval, and crypto-to-fiat transfers like Credit2Crypto and Credit2Virtual.

Tokens
116.6K
Snippets
414
Records
676
Agent score
49%

What's inside Rafinita

  1. Overview of Payment Platform SALE API capabilities

    The Payment Platform SALE API (Version 1.0.0) is used to create and manage Card SALE requests. It supports two primary transaction types: immediate payments (SALE) and authorization-only (AUTH) transactions. The API functionality is categorized into basic operations (Sale, Capture, Void, Creditvoid, Debit), card transfers (Credit2Card, Card2Card), transaction status and detail retrieval, and recurring operation management (Schedules, Retries, and Descheduling).

  2. Overview of the Checkout SDK

    The Checkout SDK is a browser-side JavaScript module that allows merchants to build fully custom-branded checkout pages (HTML/CSS/JS) hosted on the Payment Platform. It handles payment sessions, secure card-data processing, 3D-Secure redirect flows, and Apple Pay/Google Pay buttons. Because the form is hosted on the Payment Platform, merchants maintain PCI scope reduction.

    Supported Payment Methods: Currently, only CARD, ApplePay, and GooglePay are supported. P2P and debit payment forms are not supported.

  3. Overview of Hosted Payment Fields (HPF) integration

    Hosted Payment Fields allow developers to integrate payment pages without requiring PCI DSS Level 1 certification, as sensitive payment data is processed and stored on the platform. The integration supports purchase and debit operations. A critical requirement for this integration is the inclusion of the return_url parameter to ensure correct redirection after 3DS authentication. While success_url and cancel_url are optional, return_url is mandatory.

  4. Overview of the Rafinita Payments API

    Rafinita is a payment orchestration platform that allows developers to route card and alternative payments across acquirers, networks, and Alternative Payment Methods (APMs) through a single API. The platform supports card payments (Visa, Mastercard, Amex), wallets, bank transfers, crypto on/off-ramps, two-step auth + capture (DMS mode), recurring subscriptions via saved tokens, and multi-acquirer routing with cascading and pre-routing rules.

  5. Overview of Rafinita Payment Orchestration Capabilities

    Rafinita is a payment orchestration platform that allows developers to route card and alternative payments across acquirers, networks, and Alternative Payment Methods (APMs) through a single API. Key capabilities include:

    • Card Payments: Support for Visa, Mastercard, Amex, and regional schemes.
    • Alternative Payments: Support for APMs, wallets, bank transfers, and crypto on/off-ramps.
    • Transaction Management: Two-step auth + capture (DMS mode for deferred/partial captures), refunds, voids, and credits (full or partial) via server-to-server calls.
    • Recurring & Tokenization: Saved-token charges, merchant-scheduled subscriptions, and the ability to tokenize a card once for future reuse.
    • Routing: Multi-acquirer routing with cascading across providers and pre-routing rules.

  6. Overview of Rafinita Payment APIs

    Rafinita provides three primary Payment APIs based on REST principles that accept and respond with JSON. All requests must be sent via POST. For the Checkout protocol, the Content-Type: application/json header is required.

  7. Understand S2S APM hash signature fundamentals

    The hash is a signature used by the Payment Platform to validate requests sent by a system and by the system to validate callbacks sent by the platform.

    Key Technical Details:

    • Algorithm: MD5 by default. If the 'Use SHA256 encryption algorithm for hash' option is enabled in the protocol mapping, SHA256 is used instead. The input string and order remain the same regardless of the digest function.
    • Case Sensitivity: All formulas require the assembled input string to be converted to uppercase (equivalent to PHP strtoupper), which affects only a-z characters.
    • Concatenation: Values are concatenated directly with no separators or spaces.

    Notation:

    • $PASSWORD: The merchant password from the admin panel (not the client_key). This is never sent in the request, only used in the hash.
    • $identifier: The identifier request parameter (token, account info, or descriptor). If not sent, it is omitted from the hash.
    • $trans_id: The transaction ID sent in the call or received in the callback.

  8. Configure Cart Payment parameters

    Use the parameters[cart][payments] array to specify details about payment methods already applied to a cart, such as gift cards or promotions. All fields in this set are optional.
    {
  "parameters": {
    "cart": {
      "payments": [
        {
          "name": "promotion giftcard 50",
          "type": "GIFTCARD",
          "amount": "50.00",
          "currency": "USD",
          "status": "captured",
          "brand": "SVS",
          "primary": true
        }
      ]
    }
  }
}

  9. S2S Card payment request payer and payee parameters

    When initiating a SALE/AUTH request for S2S Card payments, the following optional parameters can be used to provide details about the payer and payee. All string fields have specific character limits, and the country must be provided as a 2-letter code.
    {
  "payee_email": "string (max 255)",
  "payee_phone": "string (max 32)",
  "payer_first_name": "string (max 32)",
  "payer_last_name": "string (max 32)",
  "payer_middle_name": "string (max 32)",
  "payer_birth_date": "yyyy-MM-dd (e.g. 1970-02-17)",
  "payer_address": "string (max 255)",
  "payer_address2": "string (max 255)",
  "payer_house_number": "string (max 9)",
  "payer_country": "2-letter code",
  "payer_state": "string (max 32)"
}

  10. Understand S2S CARD hash signature requirements

    The hash field is used to validate requests sent to the Payment Platform and callbacks received from it.

    Key Technical Constraints:

    • Digest Algorithm: MD5 by default. If the 'Use SHA256 encryption algorithm for hash' option is enabled in the protocol mapping, SHA256 is used instead. The input string and order remain the same regardless of the algorithm.
    • Case Sensitivity: All assembled input strings must be converted to uppercase (equivalent to PHP strtoupper), which affects only a-z characters.
    • Optional Parameters: If a formula includes an optional parameter that is not sent in the request (e.g., payer_email in a DEBIT request), that term must be omitted entirely from the hash input. Do not use empty placeholders or keep separators for missing values.

  11. Connect AI assistants to documentation via MCP

    The documentation is available via a public, read-only MCP (Model Context Protocol) server. This allows AI assistants to search and read current documentation pages, including API references and parameter tables, rather than relying on training data. The server uses streamable HTTP transport and requires no API keys or account configuration.
    https://docs.akurateco.com/mcp

  12. Compare Payment Platform integration protocols

    Payment Platform offers three primary integration protocols based on where payment data is collected and the level of merchant control required:

    1. Checkout Integration: The payer is redirected to a Payment Platform checkout page (or an embedded iframe). Payment Platform collects all required parameters. This minimizes merchant effort but reduces control over the payment experience.
    2. S2S Card (Server-to-Server): The merchant collects card details directly and transmits them to the Payment Platform via API. This requires the merchant to be PCI DSS compliant. There is no redirection except for mandatory 3DS authentication. This is exclusively for card payments.
    3. S2S APM (Server-to-Server Alternative Payment Methods): Used for APMs or connectors requiring redirection. Merchants use their own pages, bypassing the Payment Platform checkout intermediary. This provides maximum control but requires the merchant to maintain pages for specific APM parameters.