# Get started

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

Source: https://developer.inoviopay.com/get-started.html  
Markdown: https://developer.inoviopay.com/get-started.md

## 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.

**POST** `https://api.inoviopay.com/payment/pmt_service.cfm`

Verify credentials with `TESTAUTH` and gateway availability with `TESTGW`; both are on the [overview page](https://developer.inoviopay.com/api/overview.md). Test card numbers and the scripted decline scenarios are on [Testing](https://developer.inoviopay.com/api/testing.md).

## Pick a path

| If you… | Use | Time to first approved transaction |
|---|---|---|
| Run WooCommerce, Magento 2, PrestaShop 9 or OpenCart 4 | A [shopping cart plugin](https://developer.inoviopay.com/carts/index.md) | Minutes. Install, enter the five credentials, enable. |
| Have your own checkout in PHP, Node, Python or Java | A [server-side SDK](https://developer.inoviopay.com/sdks/index.md) | 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](https://developer.inoviopay.com/api/overview.md) 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](https://developer.inoviopay.com/api/tokenization.md).

## Next

- [Sale (CCAUTHCAP)](https://developer.inoviopay.com/api/sale.md): the one request most integrations start with.
- [How the SDKs think](https://developer.inoviopay.com/sdks/concepts.md): the five-state result, decimal money, idempotency.
- [Shopping cart plugins](https://developer.inoviopay.com/carts/index.md): the capability matrix and the shared refund design.