API v4.14
Markdown

Get started

What you need from Inovio, how test and production work, and which integration path to pick.

What you need from Inovio

Every integration path uses the same five values. Inovio support issues them when your account is boarded.

Credential Wire name Used by
API username REQ_USERNAME API, SDKs, plugins
API password REQ_PASSWORD API, SDKs, plugins
Site ID SITE_ID API, SDKs, plugins
Site Key (HMAC secret, never sent) Tokenization: SDKs' tokenize(), and the plugins' browser direct-post
Gateway Product ID LI_PROD_ID Plugins (the product each order bills under)
The Site Key is not the API password

It is a separate per-site HMAC secret used only to sign tokenization requests. Without it the token service answers error 121 and a plugin checkout cannot proceed. You cannot generate it yourself.

An optional Merchant Account ID (MERCH_ACCT_ID) pins transactions to one merchant account. Leave it out to let the gateway route by currency and country.

Test and production are the same endpoint

There is no sandbox host. You use the same credentials and the same URLs for testing and for live processing. What changes is how your site is configured in the Inovio portal: during testing your site points at a Test Bank merchant ID, and when you go live Inovio repoints it at your production merchant IDs. No code change is needed.

POSThttps://api.inoviopay.com/payment/pmt_service.cfm

Verify credentials with TESTAUTH and gateway availability with TESTGW; both are on the overview page. Test card numbers and the scripted decline scenarios are on Testing.

Pick a path

If you… Use Time to first approved transaction
Run WooCommerce, Magento 2, PrestaShop 9 or OpenCart 4 A shopping cart plugin Minutes. Install, enter the five credentials, enable.
Have your own checkout in PHP, Node, Python or Java A server-side SDK An hour. client.sale(request) and handle a five-state result.
Need something the SDKs do not cover yet (ACH, wallets, subscriptions) or use another language The Gateway API directly The API is one form-encoded POST; the SDK pages show the exact fields each method sends.

Where the card number goes

The gateway supports three ways the card number can reach it, from the most to the least card data on your server:

  1. Raw PAN to the API. Your server sends PMT_NUMB. Simple, but your server handles card data.
  2. Server-side tokenization. Your server calls the token service, gets a single-use TOKEN_GUID, and uses that instead of the PAN. The SDKs' tokenize() does this. The PAN still transits your server.
  3. Browser direct-post. The shopper's browser posts the PAN straight to the token service, signed with an HMAC your server minted from the Site Key. Only the token reaches you. This is what all four cart plugins do.

A browser Hosted Fields library for custom checkouts is planned; until it ships, the plugins are the reference implementation of level 3. See Tokenization.

Next