Host-to-host and aggregator integration.

The integration architecture choice that determines per-transaction cost, operational control, and time to add a new payment rail.

idataraya implements both host-to-host (H2H) direct integrations and third-party (3P) aggregator-fronted integrations, and the choice matters per rail. H2H connects your system directly to the bank, acquirer, or scheme: no intermediary, lower per-transaction fee, full control over the message format and settlement file. 3P routes through an aggregator or gateway: faster onboarding, one contract covering multiple rails, but a margin taken per transaction and less visibility into raw settlement data. The right answer is almost always a mix: H2H for high-volume rails where the fee saving justifies the integration cost, 3P for long-tail rails where the aggregator's breadth outweighs the margin.

H2H direct integration to bank, acquirer, or PayNet for high-volume rails
3P aggregator-fronted integration for multi-rail coverage with one contract
Per-rail breakdown: which model fits FPX, DuitNow, cards, wallets, and BNPL
Migration path from 3P to H2H when volume justifies the switch

Book a discovery call

Integration model selectionH2H vs 3P per rail

Running

Rail assessmentvol and feeModel decisionH2H or 3PIntegration buildcertifiedSettlement wiredraw or normalised

Migration boundary built in from day one

INT-MODEL, all railsIntegration model per rail

Verified

FPXH2H high vol, 3P low vol
CardsH2H preferred at scale
DuitNow QR, AutoDebitH2H or 3P via PayNet
E-wallets, BNPL3P via aggregator

Model per rail, migration boundary pre-built

H2H integration pathDirect to bank or acquirer

Running

Your systembackendBank or acquirer APIdirect TLSAuth or debitno intermediarySettlement fileraw, T+1

No gateway margin, full settlement visibility

3P aggregator pathOne contract, multiple rails

Running

Your systembackendAggregator or gateway3P marginFPX, DuitNowrail 1Wallets, BNPLrail 2-NOne settlementnormalised

Gateway margin per transaction, faster time to rail

Integration architecture is a cost and control decision.

H2H and 3P are not competing philosophies. They are tools applied per rail based on volume, fee sensitivity, and operational capacity. Understanding the per-rail breakdown before signing integration contracts avoids expensive rework later.

H2H: direct connection, lower fee, higher build cost.

H2H integration connects your backend directly to the bank or acquirer API. There is no gateway margin on each transaction. The tradeoffs are real: the integration is more complex, certification with the bank is required, and your team owns the protocol and the failure modes. For FPX and card acquiring at scale, H2H typically recovers the build cost within the first year of volume.

H2H integration pathDirect to bank or acquirer

Running

Your systembackendBank or acquirer APIdirect TLSAuth or debitno intermediarySettlement fileraw, T+1

No gateway margin, full settlement visibility

3P: one contract, multiple rails, faster onboarding.

A 3P aggregator sits between your integration and the rail providers. One API contract, one settlement report format, and one support relationship cover FPX, DuitNow, e-wallets, and cards simultaneously. The aggregator charges a percentage per transaction. For low-volume rails or when speed to market is the constraint, 3P is often the right starting point.

3P aggregator pathOne contract, multiple rails

Running

Your systembackendAggregator or gateway3P marginFPX, DuitNowrail 1Wallets, BNPLrail 2-NOne settlementnormalised

Gateway margin per transaction, faster time to rail

Per-rail breakdown: which model fits each payment method.

FPX and card acquiring: large merchants go H2H, smaller merchants go 3P. DuitNow QR: typically 3P (PayNet connectivity requires volume commitment to justify H2H). E-wallets: almost always 3P (five wallets under one aggregator contract). BNPL: always 3P (providers supply their own SDK). DuitNow AutoDebit: H2H via PayNet where mandate volume is high.

INT-MODEL, rail mapIntegration model per rail

Verified

FPXH2H high vol, 3P low vol
Cards (acquirer)H2H preferred at scale
DuitNow QR, AutoDebit3P or H2H via PayNet
E-wallets, BNPL3P via aggregator

Model chosen per rail based on volume and fee sensitivity

Migration path: 3P to H2H when volume justifies it.

Starting on 3P does not lock you in. idataraya builds integrations with a migration boundary so the application layer does not need to change when the underlying connectivity switches from 3P to H2H. The switch happens at the integration layer, settlement reconciliation is re-pointed, and the application sees the same callback shape.

MIGRATE, FPX, H2H3P to H2H migration

Verified

Application layerNo change required
Integration layerReconnected to bank API
Settlement reconciliationRe-pointed to bank file
Callback shapeUnchanged, same contract

Migration tested in staging before production cutover

Integration architecture designed for cost.

Integration model assessment
Per-rail analysis of H2H vs 3P fit based on your transaction volumes, fee sensitivity, and operational capacity, with a recommended model for each payment method.
H2H implementation
Direct integration to bank, acquirer, or PayNet APIs for qualifying rails, including certification, protocol implementation, and settlement file ingestion.
3P aggregator integration
Aggregator-fronted integration for multi-rail coverage, with a migration boundary built in so the application layer is not affected if connectivity switches to H2H later.
Settlement and reconciliation per model
Reconciliation configured for both H2H raw settlement files and 3P normalised reports, covering all active rails in one daily consolidated run.