🧩 Integration Overview Flow

🔌 Integration Options

Choose the integration model that best fits your product and compliance requirements:

---

1. 🧠 H2H (Host-to-Host) Integration

Use this backend-to-backend integration when you want full control over the payment process.

You send all required data — including:

• 💳 Card information
• 👤 Customer details
• 🔐 3DS authentication data

✅ Best for: PCI-compliant merchants who want direct access to the payment flow
⚠️ Note: You are responsible for securely handling card data and 3DS challenge responses.

---

2. 🧰 SDK Integration (Invisible Frontend)

Embed our JavaScript SDK into your checkout page to handle:

• 💳 Card data collection
• 💸 Payment execution
• 🔐 3DS authentication (frictionless or challenge)

The frontend initializes the SDK and receives the result asynchronously.

✅ Best for: Merchants who want a native checkout experience with less PCI scope
🛡️ Benefit: 3DS flow is handled directly by our SDK, simplifying compliance

---

3. 🌐 Checkout Page Integration (Redirect Flow)

Redirect the customer to our secure hosted checkout page, where they:

• 💳 Enter card details
• 🔐 Complete 3DS authentication
• ✅ Finalize the payment

Upon success, we redirect the customer back to your site using the configured return_url.

✅ Best for: Fast integration with minimal compliance effort
🚀 Advantage: Full UX and security handled by our platform

---

📘 Want to dive deeper into each model?
Check out our Integration Guides and API Reference for detailed

---

🎯 How to Choose the Right Integration

Use the decision tree below to quickly identify the best integration model for your use case:

flowchart TD
    Start[Which integration?] --> Q1{PCI Compliant?}
    Q1 -->|Yes| Q2{Need full control?}
    Q1 -->|No| Q3{Want native UX?}
    Q2 -->|Yes| H2H[H2H Integration]
    Q2 -->|No| Q3
    Q3 -->|Yes| SDK[SDK Integration]
    Q3 -->|No| Checkout[Checkout Page]
    H2H --> H2H_Note[Full card handling]
    SDK --> SDK_Note[SDK handles 3DS]
    Checkout --> Checkout_Note[Fastest launch]

steps and code samples.

🔍

**Click here to view full diagram with zoom **

📊 Decision Matrix

⚡ Quick Decision Rules

• 🚀 Checkout Page — Want fastest launch + minimal compliance burden
• • 🛠️ SDK — Want native checkout without handling full 3DS complexity
  • • 🔧 H2H — PCI-compliant + need maximum control over payment flow

  • ---

📋 Implementation Responsibilities

H2H (Host-to-Host)

You implement:

• Backend call to create charge (card + customer + webhook_url + wallet_uuid)
• • Handle 3DS challenge: render/redirect payer to url_3ds, process webhook result
  • • Security: HTTPS end-to-end, never log sensitive data
  • A55 provides:
  • • Immediate status for frictionless cases or url_3ds for challenge
    • • Status updates via webhook

    • SDK Integration

  • You implement:
  • • Create payment/charge in backend (to get charge_uuid)
    • • Initialize SDK in frontend for device data collection + 3DS + payment
      • • Show modal challenge when required (SDK triggers it)
      • SDK handles:
      • • DDC/fingerprint + frictionless/challenge routing + async callback

      • Checkout Page (Redirect)

    • You implement:
    • • Create charge with minimum payer/order data
      • • Redirect payer to hosted checkout URL returned by A55
        • • Process webhook updates for final state
          • • (Optional) Provide payer address for pre-fill
          • A55 handles:
          • • Card data collection + 3DS + payment completion inside hosted page

          • ---

      • 🔔 Status Updates & Source of Truth

    • Important: Regardless of the integration model, treat the webhook as the source of truth for the final payment outcome. Terminal states: paid, error, canceled, refunded — these do not transition further.

  • Recommended UX Pattern

• 
  

Best Practice: Show "processing/pending" until webhook confirms final state. Never rely solely on frontend responses.