Get your provider data
in one place,
in a shape you can reconcile
Integration Gateway connects to the payment providers, gateways and partner platforms you already work with, normalises what comes back, and lands it in storage you control.
Every provider exports differently.
Your warehouse shouldn’t care.
One acquirer sends settlement files over SFTP at midnight. An APM posts webhooks. A partner platform has an API with its own ideas about field names and time zones. Multiply by every provider you work with, and “just get the data” becomes a permanent engineering project that never quite finishes.
Integration Gateway is that project, finished. Connectors on one side, one consistent model on the other — providers, products, projects, geographies — landing in your own storage.
Two collection modes, chosen per provider
Each connector uses whichever mode the provider supports. Both land in the same model.
Scheduled pull
Miraxtech requests data from the provider on an interval you set, at the depth you set. Used where the provider offers no push mechanism.
- Initiated by
- Miraxtech, on your schedule
- Interval
- Configured per provider
- Depth
- Configured per provider
Real-time push
The provider posts data to your endpoint as events happen.
- Initiated by
- The provider
- Timing
- As events happen
- Destination
- An endpoint inside your perimeter
settlements_0825.csv1,204 rowsmapped ✓ apm_aggpushwebhook batch388 eventsmapped ✓ wallet_01pulltx_export.json2,051 rowsenriched ✓ bank_cypullcamt.053117 entriesmapped ✓ partner_nrpushaffiliate_stats4,800 rowsmapped ✓ acq_latampullsettlements_0825.csv966 rowsenriched ✓ acq_eupullsettlements_0825.csv1,204 rowsmapped ✓ apm_aggpushwebhook batch388 eventsmapped ✓ wallet_01pulltx_export.json2,051 rowsenriched ✓ bank_cypullcamt.053117 entriesmapped ✓ partner_nrpushaffiliate_stats4,800 rowsmapped ✓ acq_latampullsettlements_0825.csv966 rowsenriched ✓Data arrives usable, not raw
| Provider field | Rule on load | Lands as |
|---|---|---|
| txn_dtlocal time, no offset | Time-zone normalisation | transaction_utc |
| fee_amtminor units | Scale and currency | fee_amount |
| merch_ref | Automatic replacement | project_id |
| —absent from the export | Template value | provider_id |
| cc | Enrichment on load | geography |
Illustrative scheme · field names and rules differ per provider
A field-matching layer sits between each provider’s format and your database. Automatic replacements and template values fill the gaps; serialisation and enrichment rules run during load. What reaches the warehouse is already consistent — no cleanup pass, no “we’ll fix it in the report”.
Customers on the Miraxtech SQL warehouse template get pre-configured mapping schemes, so a new connector drops into a known structure rather than a blank page.
What we connect to
Ready-made integration interfaces with more than 40 payment providers, gateways and partner platforms.
We don’t publish a provider list — most of them prefer we didn’t. Send us your mix and we’ll confirm what’s already built and what needs building.
Coverage by category. Individual providers are not named.
Common questions
- Our provider isn’t in your coverage. Now what?
- We build the connector to order. The integration layer is the part we’ve done most often, so a new provider is measured in weeks, not quarters.
- Where does the data actually go?
- Into storage you control, inside your own perimeter. Miraxtech holds no copy of it.
- Does the Gateway run without the other Miraxtech products?
- Yes — every Miraxtech product is its own platform and runs standalone. If you also run PSP Fees Reconciliation, the Gateway can serve as its import route, but neither requires the other.
- How current is “real time”?
- Push connectors deliver as the provider posts events. Pull connectors run on the schedule and depth you configure per provider.
Send us your provider mix
We’ll reply with a specific answer: what’s covered, what needs building.