# NMI Developer Documentation Documentation > Build and monetize your payment solutions faster with NMI’s Developer Documentation. Designed for software platforms, our components, APIs, SDKs, and integration guides help you embed payments seamlessly, reduce time to first transaction, and deliver a unified commerce experience across every channel. ## Guides - [Explore Payment Solutions](https://docs.nmi.com/docs/quick-start.md) - [Get Your API Keys](https://docs.nmi.com/docs/getting-your-api-keys.md) - [Third Party Integrations](https://docs.nmi.com/docs/third-party-integrations.md) - [Classic API Migration Playbook](https://docs.nmi.com/docs/payment-migration-playbook.md) - [Code Examples](https://docs.nmi.com/docs/payment-code-examples.md) - [Online Checkout Flow](https://docs.nmi.com/docs/online-checkout-design.md) - [Customer-Friendly Surcharge](https://docs.nmi.com/docs/compliant-surcharge-toolkit.md) - [Merchant Sign-Up](https://docs.nmi.com/docs/toolkit-merchant-signup.md) - [Online Payments Overview](https://docs.nmi.com/docs/online-payments-overview.md): Build secure, scalable payment solutions with NMI's comprehensive online payments platform. Whether you're creating a custom checkout experience or need a quick-to-deploy solution, our flexible tools and APIs adapt to your business needs. - [Hosted Checkout](https://docs.nmi.com/docs/hosted-checkout.md): Collect Checkout is the no code checkout solution - [Quick Start Guide](https://docs.nmi.com/docs/quick-start-guide-copy.md): Use a prebuilt checkout page to accept payments in minutes. - [Advanced Integration](https://docs.nmi.com/docs/advanced-integration.md) - [Payment Component](https://docs.nmi.com/docs/payment-component.md): Secure payment processing using NMI's tokenization system - [Integrating the Frontend Component](https://docs.nmi.com/docs/integration-guide-implement-frontend.md) - [Implement Backend](https://docs.nmi.com/docs/integration-guide-implement-backend.md) - [Test and Deploy](https://docs.nmi.com/docs/integration-guide-test-and-deploy.md): Test cards and methods for development - [Customize Styling](https://docs.nmi.com/docs/integration-guide-customize-styling.md) - [Surcharging with Card Type Detection](https://docs.nmi.com/docs/card-type-detection.md) - [Custom Checkout](https://docs.nmi.com/docs/custom-checkout.md) - [Adding Digital Wallet Data to the Customer Vault](https://docs.nmi.com/docs/adding-digital-wallet-data-to-the-customer-vault.md) - [Full Transaction Lifecycle Example](https://docs.nmi.com/docs/full-transaction-lifecycle-example.md) - [Preparing Subscriptions using Digital Wallet Data](https://docs.nmi.com/docs/preparing-subscriptions-using-digital-wallet-data.md) - [Full Transaction Lifecycle Example](https://docs.nmi.com/docs/full-transaction-lifecycle-example-1.md) - [Account Funding Transactions](https://docs.nmi.com/docs/account-funding-transactions.md) - [FSA/HSA](https://docs.nmi.com/docs/fsahsa.md) - [Customer Vault](https://docs.nmi.com/docs/customer-vault.md): Secure storage and tokenization of customer payment information - [Adding Customers to Vault](https://docs.nmi.com/docs/adding-customers-to-vault.md): Add a new customer to the vault with their payment information by calling the NMI Payments API. - [Managing Entries](https://docs.nmi.com/docs/managing-entries.md): Update existing customer information and delete entries as needed. - [Using for Transactions](https://docs.nmi.com/docs/using-for-transactions.md): Process one-time sales for recurring customers using vault tokens with your merchant API key - [Credential on File Best Practices](https://docs.nmi.com/docs/credential-on-file.md) - [Collect.js](https://docs.nmi.com/docs/collectjs.md): Collect payments on your website securely, and beautifully - [Quick Start Guide](https://docs.nmi.com/docs/quick-start-tutorial.md): Accept payments online in four easy steps - [Advanced Integrations](https://docs.nmi.com/docs/advanced-integrations.md): Customize the appearance of your checkout page. - [Digital Wallet Setup](https://docs.nmi.com/docs/digital-wallet-setup.md): Accept ApplePay and GooglePay payments - [Surcharging with Card Type Detection (Collect.js)](https://docs.nmi.com/docs/surcharge-with-card-type-detection-collectjs.md) - [In-Person Payments Overview](https://docs.nmi.com/docs/in-person-payments-overview.md): Flexible in-person payments, built your way - [Android All in One SmartPOS: Ingenico Axium](https://docs.nmi.com/docs/android-all-in-one-smartpos-ingenico-axium.md): Your integration. Upgraded. - [Enabling Test Mode](https://docs.nmi.com/docs/enable-test-mode-1.md): Test your integration by accessing our sandbox environment - [EMV Sandbox Environment](https://docs.nmi.com/docs/emv-sandbox-environment.md) - [Getting Started](https://docs.nmi.com/docs/getting-started.md) - [Requests & Responses](https://docs.nmi.com/docs/requests-responses.md) - [Validation Errors](https://docs.nmi.com/docs/validation-errors.md) - [Tap to Pay on iPhone](https://docs.nmi.com/docs/mobile-point-of-sale-tap-to-pay-on-iphone.md): Bring Tap to Pay to your app—no extra hardware required - [Enable Tap to Pay ](https://docs.nmi.com/docs/enable-tap-to-pay-on-iphone-to-do.md) - [Downloading the SDK](https://docs.nmi.com/docs/downloading-the-ios-sdk.md) - [Unboxing the iOS SDK](https://docs.nmi.com/docs/unboxing-the-ios-sdk.md) - [Creating and Managing Security Keys](https://docs.nmi.com/docs/creating-and-managing-security-keys-1.md) - [Preparing for Development](https://docs.nmi.com/docs/preparing-for-development-1.md) - [Firewall Configuration](https://docs.nmi.com/docs/firewall-configuration-1.md) - [Transaction Flow](https://docs.nmi.com/docs/transaction-flow-2.md) - [Sequence Diagrams](https://docs.nmi.com/docs/sequence-diagrams.md) - [Modes of Operation](https://docs.nmi.com/docs/modes-of-operation-2.md) - [Configuration](https://docs.nmi.com/docs/configuration-2.md) - [Configuration and Utility Methods](https://docs.nmi.com/docs/configuration-and-utility-methods-2.md) - [Configuration and Utility Events](https://docs.nmi.com/docs/configuration-and-utility-events-2.md) - [Start Transaction](https://docs.nmi.com/docs/start-transaction.md) - [Transaction Events](https://docs.nmi.com/docs/transaction-events.md) - [Receipts](https://docs.nmi.com/docs/receipts-1.md) - [Supported Features](https://docs.nmi.com/docs/supported-features.md) - [User Experience Requirements](https://docs.nmi.com/docs/user-experience-requirements.md) - [Regional Requirements](https://docs.nmi.com/docs/regional-requirements.md) - [Preparing for Release](https://docs.nmi.com/docs/preparing-for-release-1.md) - [Entitlement Review](https://docs.nmi.com/docs/entitlement-review.md) - [Frequently Asked Questions](https://docs.nmi.com/docs/frequently-asked-questions.md): For merchants, partners, and integrators - [Tap to Pay on Android](https://docs.nmi.com/docs/mobile-point-of-sale-tap-to-pay-on-android.md): Bring Tap to Pay to your app—no extra hardware required - [Enable Tap to Pay](https://docs.nmi.com/docs/enable-tap-to-pay-android.md) - [Downloading the Android SDK](https://docs.nmi.com/docs/downloading-the-sdk-android.md) - [Unboxing the Android SDK](https://docs.nmi.com/docs/unboxing-the-sdk-android.md) - [Creating and Managing Security Keys](https://docs.nmi.com/docs/creating-and-managing-security-keys-android.md) - [Preparing for Development](https://docs.nmi.com/docs/preparing-for-development-android.md) - [App Onboarding](https://docs.nmi.com/docs/app-onboarding-android.md): kananaffiliate - [Firewall Configuration](https://docs.nmi.com/docs/firewall-configuration-android.md) - [Transaction Flow](https://docs.nmi.com/docs/transaction-flow-android.md) - [Sequence Diagrams](https://docs.nmi.com/docs/sequence-diagrams-android.md) - [Modes of Operation](https://docs.nmi.com/docs/modes-of-operation-android.md) - [Configuration](https://docs.nmi.com/docs/configuration-android.md) - [Configuration and Utility Methods](https://docs.nmi.com/docs/configuration-and-utility-methods-android.md) - [Configuration and Utility Events](https://docs.nmi.com/docs/configuration-and-utility-events-android.md) - [Start Transaction](https://docs.nmi.com/docs/start-transaction-android.md) - [Transaction Events](https://docs.nmi.com/docs/transaction-events-android.md) - [Receipts](https://docs.nmi.com/docs/receipts-android.md) - [Supported Features](https://docs.nmi.com/docs/supported-features-android.md) - [Contactless Symbol Reproduction Requirements](https://docs.nmi.com/docs/contactless-symbol-reproduction-requirements-android.md) - [Frequently Asked Questions](https://docs.nmi.com/docs/frequently-asked-questions-android.md): For merchants, partners, and integrators - [VP3350](https://docs.nmi.com/docs/mobile-point-of-sale-vp3350.md): Everything you need to build and test in-person payments fast - [Unboxing your VP3350 device](https://docs.nmi.com/docs/unboxing-your-vp3350-device.md) - [Enable Test Mode](https://docs.nmi.com/docs/enable-test-mode.md) - [Downloading the Android/iOS SDK](https://docs.nmi.com/docs/downloading-the-sdk.md) - [Unboxing the Android/iOS SDK ](https://docs.nmi.com/docs/unboxing-the-sdk.md) - [Creating and Managing Security Keys](https://docs.nmi.com/docs/creating-and-managing-security-keys.md) - [Platform Specific Requirements](https://docs.nmi.com/docs/platform-specific-requirements-1.md) - [Firewall Configuration](https://docs.nmi.com/docs/firewall-configuration.md) - [Transaction Flow](https://docs.nmi.com/docs/transaction-flow-1.md) - [Configuration](https://docs.nmi.com/docs/configuration-1.md) - [Configuration and Utility Methods](https://docs.nmi.com/docs/configuration-and-utility-methods-1.md) - [Configuration and Utility Events](https://docs.nmi.com/docs/configuration-and-utility-events-1.md) - [Payment Methods](https://docs.nmi.com/docs/payment-methods-1.md) - [Payment Events](https://docs.nmi.com/docs/payment-events-1.md) - [Deferred Authorizations](https://docs.nmi.com/docs/deferred-authorizations-1.md) - [TMS Properties ](https://docs.nmi.com/docs/tms-properties.md) - [Receipts](https://docs.nmi.com/docs/receipts.md) - [App Submission](https://docs.nmi.com/docs/app-submission.md) - [Appendix: Quick Reference Tables](https://docs.nmi.com/docs/quick-reference-tables.md) - [Axium SmartPOS](https://docs.nmi.com/docs/smart-pos-ingenico-axium.md): Axium SmartPOS. Powerful hardware, developer-first. - [Unboxing your Axium device](https://docs.nmi.com/docs/unboxing-your-axium-device.md) - [Device setup](https://docs.nmi.com/docs/device-setup.md) - [Platform-specific requirements](https://docs.nmi.com/docs/platform-specific-requirements-axium.md) - [Configuration](https://docs.nmi.com/docs/configuration-axium.md) - [Transaction flow](https://docs.nmi.com/docs/transaction-flow-axium.md) - [Configuration and utility events](https://docs.nmi.com/docs/configuration-and-utility-events-axium.md) - [Offline transactions](https://docs.nmi.com/docs/offline-transactions.md) - [Device disconnection](https://docs.nmi.com/docs/device-disconnection.md) - [OTA updates](https://docs.nmi.com/docs/ota-updates.md) - [Retrieving log files](https://docs.nmi.com/docs/retrieving-log-files.md) - [All-in-One Development](https://docs.nmi.com/docs/all-in-one.md) - [Setup for development](https://docs.nmi.com/docs/setup-for-development.md) - [Hosted Estate Manager (HEM)](https://docs.nmi.com/docs/hem-overview.md) - [Partner onboarding with a Partner Code](https://docs.nmi.com/docs/partner-code-onboarding.md) - [Managing devices & estates](https://docs.nmi.com/docs/managing-devices-and-estates.md) - [Software library & campaigns](https://docs.nmi.com/docs/software-and-campaigns.md) - [MDM profiles](https://docs.nmi.com/docs/mdm-profiles.md) - [User management & access](https://docs.nmi.com/docs/user-management.md) - [Application signing](https://docs.nmi.com/docs/application-signing.md) - [Appendix 1 — Supported API methods](https://docs.nmi.com/docs/appendix-1-supported-api-methods.md) - [Appendix 2 — Unsupported features](https://docs.nmi.com/docs/appendix-2-unsupported-features.md) - [Lane/Series](https://docs.nmi.com/docs/countertop-point-of-sale-lane3600.md): Everything you need to build and test in-person payments fast - [Unboxing your Lane device](https://docs.nmi.com/docs/unboxing-your-lane3600-device.md) - [Enabling Encrypted Devices](https://docs.nmi.com/docs/enabling-encrypted-devices-1.md) - [Introduction to the Customer Present Cloud API](https://docs.nmi.com/docs/introduction-to-the-customer-present-cloud-api.md) - [Registering Your Device](https://docs.nmi.com/docs/registering-your-device.md) - [Device Estate Management](https://docs.nmi.com/docs/device-estate-management.md) - [Standalone Device Inputs](https://docs.nmi.com/docs/standalone-device-inputs.md) - [Processing](https://docs.nmi.com/docs/processing.md) - [AsyncStatus Polling](https://docs.nmi.com/docs/asyncstatus-polling.md) - [POI Device Prompts](https://docs.nmi.com/docs/poi-device-prompts.md) - [FSA Support](https://docs.nmi.com/docs/fsa-support.md): Pass through healthcare specific fields to your processor to benefit from preferred transaction rates. - [Virtual PIN Pad](https://docs.nmi.com/docs/virtual-pin-pad.md) - [Error Recovery Tips](https://docs.nmi.com/docs/error-recovery-tips-1.md) - [Self/Series](https://docs.nmi.com/docs/unattended-point-of-sale-selfseries.md): The fastest way to add secure unattended card payments to your machines - [Enable Encrypted Devices](https://docs.nmi.com/docs/enable-encrypted-devices.md) - [Downloading the Windows & Linux SDK ](https://docs.nmi.com/docs/downloading-the-windows-linux-sdk.md) - [Enable Allowlisting on Your Payment Device](https://docs.nmi.com/docs/enabling-allowlisting-on-your-payment-device.md): How to enable allowlisting when collecting non-payment card data. - [Test Card Simulator ](https://docs.nmi.com/docs/test-card-simulator.md): Test contactless. No cards required - [Device SDKs & APIs](https://docs.nmi.com/docs/device-sdks-apis.md): From code to checkout—devices made simple - [SDKs for Android & iOS](https://docs.nmi.com/docs/device-sdk-ios-android.md): Payments in your pocket—powered by our SDKs - [SDKs for Windows & Linux](https://docs.nmi.com/docs/device-sdks-windowslinux-1.md): Seamless payments for self-service experiences - [Customer Present Cloud API](https://docs.nmi.com/docs/device-api-cloud.md): Cloud-first control for card-present commerce - [Direct Connect ](https://docs.nmi.com/docs/direct-connect.md): Build and deploy payment-ready devices with direct EMV processing on the NMI platform. - [Direct Connect API & SDKs](https://docs.nmi.com/docs/about-direct-connect.md) - [Terminal Management](https://docs.nmi.com/docs/terminal-management.md) - [EMV Sandbox](https://docs.nmi.com/docs/emv-sandbox.md): Reduce certification risk with fast, self-service EMV testing. - [Deposit Summary Component](https://docs.nmi.com/docs/deposit-summary-component.md): Detailed deposit information including transaction breakdown and transactions - [Deposit History Component](https://docs.nmi.com/docs/deposit-reporting-component.md): Displays a report of deposit information with filtering capabilities - [Transaction History Component](https://docs.nmi.com/docs/transaction-reporting-component.md): Filterable transaction table to view, manage, and export transaction data - [Gateway Components (Gateway.js)](https://docs.nmi.com/docs/gatewayjs.md): Add Gateway services to your integration. - [Payer Authentication (3DS)](https://docs.nmi.com/docs/payer-authentication-3ds.md): 3-D Secure reduces your e-commerce payment fraud risk and increases customer confidence. - [Testing](https://docs.nmi.com/docs/testing.md): Testing Values for Payer Authentication - [Testing - Sandbox](https://docs.nmi.com/docs/testing-sandbox.md): Testing Values for Payer Authentication - [Kount Fraud Management](https://docs.nmi.com/docs/kount.md): Leading AI-Driven Fraud Prevention for eCommerce and mCommerce - [CardEase 3DS Server Integration](https://docs.nmi.com/docs/cardease-3ds-server-integration.md): 3DS Server for CardEase partners - [MCP](https://docs.nmi.com/docs/mcp.md) - [The Appearance API](https://docs.nmi.com/docs/the-appearance-api.md): An NMI theming standard for styling any component in our component library ## API Reference - [Getting Started with Our APIs](https://docs.nmi.com/reference/getting-started.md) - [Authentication](https://docs.nmi.com/reference/authentication.md): API authentication using security keys, with best practices for merchants and partners. - [Create a Session](https://docs.nmi.com/reference/create-embedded-component-session.md): This endpoint creates a short-lived session token that your embedded components can use to authenticate and fetch data. You must call this endpoint from your backend server to avoid exposing your API key. - [Testing Methods](https://docs.nmi.com/reference/testing-methods.md) - [Rate Limiting](https://docs.nmi.com/reference/rate-limiting.md) - [Pagination](https://docs.nmi.com/reference/pagination.md) - [Response Codes](https://docs.nmi.com/reference/response-codes.md) - [Overview](https://docs.nmi.com/reference/sign-up-api.md) - [Authentication](https://docs.nmi.com/reference/authentication-1.md): The Authorization endpoint allows clients to securely authenticate and obtain an access token for making requests to the API. - [Request an Access Token](https://docs.nmi.com/reference/getaccesstoken.md): This endpoint issues an OAuth access token via an HTTP POST request. The token remains valid for 60 minutes. After expiration, you must request a new token. ### Available Scopes and their access | Scope | Description | |---|---| | packages:read | Read packages information | | applications:read | Read access to applications | | applications:write | Write access to applications | | subscriptions:read | Read access to subscriptions | | subscriptions:write | Write access to subscriptions (subscribe/updated/delete) | - [List all Packages](https://docs.nmi.com/reference/getpackages.md): This operation returns a list of available application packages. **Required scope:** `packages:read` - [Get Package](https://docs.nmi.com/reference/getpackagebyid.md): The **Packages** endpoint provides package rules, a structured set of field details necessary for creating an application. It defines the required and optional fields, their formats, and any conditional rules that must be followed. **Required scope:** `packages:read` - [List all Applications](https://docs.nmi.com/reference/getapplications.md): This operation returns a list of applications. You can filter applications by: - `status`: Filter by application status (e.g. "draft", "submitted", "approved", etc.) - `updated_from`: Filter applications updated on or after a specific date (YYYY-MM-DD) - `updated_to`: Filter applications updated on or before a specific date (YYYY-MM-DD) - `package`: Filter by package ID - `sort_dir`: Sort by updated_at in ascending or descending order (values: asc, desc, default: desc) Example: `GET /applications?status=submitted&updated_from=2025-01-01&updated_to=2025-03-01&sort_dir=asc` **Required scope:** `applications:read` - [Create a new application](https://docs.nmi.com/reference/createapplication.md): In the Sandbox environment, the application's status is determined by the **Monthly Volume Field** (`fld_monthly_volume`). Based on this value, the system will send one of the following webhook events: ### Pending * Webhook event: `application.updated.data.requested` * Monthly volume is **greater than or equal to $100,000** ### Approved * Webhook event: `application.approved` * Monthly volume is **between $5,000 and $99,999** ### Declined * Webhook event: `application.declined` * Monthly volume is **less than $5,000** **Required scope:** `applications:write` - [Get Application Information](https://docs.nmi.com/reference/getapplication.md): Returns information about a given application **Required scope:** `applications:read` - [Update an Application](https://docs.nmi.com/reference/updateapplication.md): Partially update an application. An application can be updated only when it is in `draft` status. **Required scope:** `applications:write` - [Get Legal Consent](https://docs.nmi.com/reference/getapplicationlegalconsent.md): Get the legal consent URL for the application. Legal consent is required prior to application submission. Once you have the legal consent URL use Embed Helper to embed the widget into your form. Please refer to the [Legal Consent Helper](/reference/legal-consent-helper) section for more information. **Required scope:** `applications:read` - [Download Signed Agreement](https://docs.nmi.com/reference/getapplicationdownloadagreement.md): This endpoint downloads the signed agreement for the application. The agreement can only be downloaded after the application is submitted. **Required scope:** `applications:read` - [Upload Document](https://docs.nmi.com/reference/uploaddocument.md): Provide supporting documents for the application. Documents can only be uploaded while the application is the `draft` or `underwriter_requested_information` status. **Required scope:** `applications:write` - [Submit Application](https://docs.nmi.com/reference/submitapplication.md): Submit the application for review To expedite the merchant application underwriting process it is recommended to include the __Bank or Processing Statement (3 Months of Statements)__ if the merchant meets any of these criteria: * `fld_average_ticket ≥ 1000` * `fld_high_ticket ≥ 2500` **Required scope:** `applications:write` - [Update Application Information](https://docs.nmi.com/reference/updateapplicationinfo.md): Add more information to an application that is in the `underwriter_requested_information` status. - [Webhook Subscriptions](https://docs.nmi.com/reference/msu-webhook-subscriptions.md) - [List all Subscriptions](https://docs.nmi.com/reference/getsubscriptions.md): This operation returns a list of subscriptions. **Required scope:** `subscriptions:read` - [Create a Subscription](https://docs.nmi.com/reference/createsubscription.md): Creates a new subscription based on the provided data. #### How signing requests work When setting up, it's common to generate, store, and share a secret between your app and the app that wants to receive webhooks. The secret should be a random string, and how to create it is entirely up to you. The package will use the secret to sign a webhook call. By default, the package will add a header called ```Signature``` that will contain a signature the receiving app can use if the payload hasn't been tampered with. **Required scope:** `subscriptions:write` - [Get Subscription Information](https://docs.nmi.com/reference/getsubscription.md): Returns information about a given subscription **Required scope:** `subscriptions:read` - [Update a Subscription](https://docs.nmi.com/reference/updatesubscription.md): Updates an subscription **Required scope:** `subscriptions:write` - [Delete a Subscription](https://docs.nmi.com/reference/deletesubscription.md): Deletes a subscription **Required scope:** `subscriptions:write` - [Webhook Events](https://docs.nmi.com/reference/webhook-events-2.md) - [Underwriter Requested Information](https://docs.nmi.com/reference/sendapplicationupdateddatarequestedevent.md): This event is triggered when additional information is requested during underwriting process. - [Application is approved](https://docs.nmi.com/reference/sendapplicationapprovedevent.md): Sent when the merchant application is approved. - [Application is declined](https://docs.nmi.com/reference/sendapplicationdeclinedevent.md): This event is triggered when the merchant application is declined. - [Application is cancelled](https://docs.nmi.com/reference/sendapplicationcancelledevent.md): This event is triggered when the merchant application is cancelled. - [Merchant is ready to process](https://docs.nmi.com/reference/sendapplicationmerchantboardedevent.md): This event is triggered when the merchant is boarded and ready to process. - [Merchant account is closed](https://docs.nmi.com/reference/sendapplicationmerchantclosedevent.md): This event is triggered when the merchant account is closed. - [Merchant: New Chargeback](https://docs.nmi.com/reference/sendmerchantchargebackaddedevent.md): This event is triggered when a chargeback is added for a merchant. - [Merchant: New Deposit](https://docs.nmi.com/reference/sendmerchantdepositnewevent.md): This event is triggered when a new deposit is made for a merchant. - [Merchant: First Batch](https://docs.nmi.com/reference/sendmerchantfirstbatchevent.md): This event is triggered when a merchant processes their first batch of transactions. - [Merchant: Started Processing](https://docs.nmi.com/reference/sendmerchantprocessingstartevent.md): This event is triggered when a merchant starts processing transactions. - [Merchant: Stopped Processing](https://docs.nmi.com/reference/sendmerchantprocessingstopevent.md): This event is triggered when a merchant stops processing transactions. - [Merchant: Residual Report Published](https://docs.nmi.com/reference/sendmerchantresidualspublishedevent.md): This event is triggered when merchant residuals reports are published. - [Merchant: New Retrieval](https://docs.nmi.com/reference/sendmerchantretrievaladdedevent.md): This event is triggered when a retrieval is added for a merchant. - [Merchant: New Statement](https://docs.nmi.com/reference/sendmerchantstatementnewevent.md): This event is triggered when a new statement is available for a merchant. - [Legal Consent Helper](https://docs.nmi.com/reference/legal-consent-helper.md) - [Sale](https://docs.nmi.com/reference/create-sale-v5.md): Process a sale. This request authorizes and captures the payment in a single step. - [Authorization](https://docs.nmi.com/reference/create-auth-v5.md): Process an authorization for a payment. Use in conjunction with the capture endpoint to prepare the payment for settlement. - [Credit](https://docs.nmi.com/reference/create-credit-v5.md): Process a credit without a prior payment. This endpoint credits funds to the customer's payment method. - [Validate](https://docs.nmi.com/reference/validate-payment-v5.md): Validate a payment method without processing a payment. - [Capture](https://docs.nmi.com/reference/capture-payment-v5.md): Capture a previously authorized payment. - [Void](https://docs.nmi.com/reference/void-payment-v5.md): Void a payment. Only payments that have not yet been settled can be voided. - [Refund](https://docs.nmi.com/reference/refund-payment-v5.md): Refund a payment. Only a previously settled transaction can be refunded back to the customer's payment method. - [Get](https://docs.nmi.com/reference/get-payment-v5.md): Retrieve details for a specific payment by payment ID. - [Create Invoice](https://docs.nmi.com/reference/create-invoice-v5.md): Create a new invoice and email it to the customer. - [List Invoices](https://docs.nmi.com/reference/list-invoices-v5.md): Retrieve a list of all invoices for the merchant with optional filtering and pagination. - [Get Invoice](https://docs.nmi.com/reference/get-invoice-v5.md): Retrieve a specific invoice by its ID. - [Update Invoice](https://docs.nmi.com/reference/update-invoice-v5.md): Update an existing invoice. All variables (besides currency) on an invoice may be updated. Updating an invoice will not result in a new invoice being sent to the customer. - [Close Invoice](https://docs.nmi.com/reference/close-invoice-v5.md): Close an existing invoice. Once closed, the invoice cannot be modified or paid. - [Send Invoice](https://docs.nmi.com/reference/send-invoice-v5.md): Send an existing invoice to a customer via email. - [Create Subscription](https://docs.nmi.com/reference/create-subscription-v5.md): Create a new subscription. A subscription can be associated with an existing plan or created as a custom subscription. - [List Subscriptions](https://docs.nmi.com/reference/list-subscriptions-v5.md): Retrieve a list of all subscriptions. - [Get Subscription](https://docs.nmi.com/reference/get-subscription-v5.md): Retrieve details for a specific subscription. - [Update Subscription](https://docs.nmi.com/reference/update-subscription-v5.md): Update an existing subscription's billing information. - [Delete Subscription](https://docs.nmi.com/reference/delete-subscription-v5.md): Delete a subscription. Customer will no longer be charged. - [Create Plan](https://docs.nmi.com/reference/create-plan-v5.md): Create a new recurring payment plan. Plans can be used to define recurring billing schedules that subscriptions can be associated with. - [List Plans](https://docs.nmi.com/reference/list-plans-v5.md): Retrieve a list of all recurring payment plans. - [Get Plan](https://docs.nmi.com/reference/get-plan-v5.md): Retrieve details for a specific recurring payment plan. - [Update Plan](https://docs.nmi.com/reference/update-plan-v5.md): Update an existing recurring payment plan. Be careful when updating an existing plan, as all customers signed up for this plan will have their billing changed based on your edits. - [Delete Plan](https://docs.nmi.com/reference/delete-plan-v5.md): Delete a recurring payment plan. - [Create Customer](https://docs.nmi.com/reference/create-customer-v5.md): Create a new customer in the customer vault with billing and optional shipping information. The billing field can be either a single object or an array of objects to create multiple billing addresses at once. - [List Customers](https://docs.nmi.com/reference/list-customers-v5.md): Retrieve a list of all customers for the merchant with optional filtering and cursor-based pagination. - [Get Customer](https://docs.nmi.com/reference/get-customer-v5.md): Retrieve a specific customer by its ID. - [Update Customer](https://docs.nmi.com/reference/update-customer-v5.md): Update an existing customer. Supports bulk updates of billing and shipping addresses. All provided billing and shipping addresses will be updated. - [Delete Customer](https://docs.nmi.com/reference/delete-customer-v5.md): Delete a customer from the customer vault. This will remove the customer and all associated billing and shipping addresses. - [Add Billing Address](https://docs.nmi.com/reference/add-billing-address-v5.md): Add a new billing address to an existing customer. - [Get Billing Address](https://docs.nmi.com/reference/get-billing-address-v5.md): Retrieve a specific billing address for a customer. - [Update Billing Address](https://docs.nmi.com/reference/update-billing-address-v5.md): Update an existing billing address for a customer. - [Delete Billing Address](https://docs.nmi.com/reference/delete-billing-address-v5.md): Delete a billing address from a customer. The customer must have at least one billing address remaining. - [Add Shipping Address](https://docs.nmi.com/reference/add-shipping-address-v5.md): Add a new shipping address to an existing customer. - [Get Shipping Address](https://docs.nmi.com/reference/get-shipping-address-v5.md): Retrieve a specific shipping address for a customer. - [Update Shipping Address](https://docs.nmi.com/reference/update-shipping-address-v5.md): Update an existing shipping address for a customer. - [Delete Shipping Address](https://docs.nmi.com/reference/delete-shipping-address-v5.md): Delete a shipping address from a customer. - [Create Product](https://docs.nmi.com/reference/create-product-v5.md): Create a new product in the Product Manager. Products can be used in invoices and other payment flows. - [List Products](https://docs.nmi.com/reference/list-products-v5.md): Retrieve a list of all products in the Product Manager. - [Get Product](https://docs.nmi.com/reference/get-product-v5.md): Retrieve details for a specific product by SKU. - [Update Product](https://docs.nmi.com/reference/update-product-v5.md): Update an existing product in the Product Manager. - [Delete Product](https://docs.nmi.com/reference/delete-product-v5.md): Delete a product from the Product Manager. - [TXT2PAY (Powered by Authvia)](https://docs.nmi.com/reference/extensions-txt2pay.md): Accept payments by text - [Create a new conversation](https://docs.nmi.com/reference/post_v4-authvia-conversations.md) - [List and filter conversations](https://docs.nmi.com/reference/get_v4-authvia-conversations.md) - [Get a conversation](https://docs.nmi.com/reference/get-v4-authvia-conversations-conversation-id.md) - [Close a conversation](https://docs.nmi.com/reference/delete-v4-authvia-conversations-conversation-id.md) - [List Cloud Devices](https://docs.nmi.com/reference/list-devices-v5.md): Retrieve a list of all cloud devices registered to the merchant with optional pagination and status information. - [Register Cloud Device](https://docs.nmi.com/reference/register-device-v5.md): Register a new cloud device with the merchant using a registration code. - [Get Cloud Device](https://docs.nmi.com/reference/get-device-v5.md): Retrieve a specific cloud device by its ID. - [Update Cloud Device](https://docs.nmi.com/reference/update-device-v5.md): Update a cloud device's nickname or default status. - [Deregister Cloud Device](https://docs.nmi.com/reference/deregister-device-v5.md): Deregister a cloud device from the merchant. Once deregistered, the device cannot be used for transactions. - [Prompt Device for Signature](https://docs.nmi.com/reference/prompt-device-sign-v5.md): Prompt a cloud device to request a signature from the user. - [Get Signature Prompt Status](https://docs.nmi.com/reference/get-device-prompt-sign-status-v5.md): Retrieve the status of a signature prompt request initiated on a cloud device. The reference is obtained from the initial prompt request response (e.g., from POST /api/v5/devices/{deviceId}/prompt/sign). - [Prompt Device for Yes/No Response](https://docs.nmi.com/reference/prompt-device-yes-no-v5.md): Prompt a cloud device to request a yes/no response from the user. - [Get Yes/No Prompt Status](https://docs.nmi.com/reference/get-device-prompt-yes-no-status-v5.md): Retrieve the status of a yes/no prompt request initiated on a cloud device. The reference is obtained from the initial prompt request response (e.g., from POST /api/v5/devices/{deviceId}/prompt/yes-no). - [Prompt Device for Menu Selection](https://docs.nmi.com/reference/prompt-device-menu-v5.md): Prompt a cloud device to request a menu selection from the user. - [Get Menu Prompt Status](https://docs.nmi.com/reference/get-device-prompt-menu-status-v5.md): Retrieve the status of a menu selection prompt request initiated on a cloud device. The reference is obtained from the initial prompt request response (e.g., from POST /api/v5/devices/{deviceId}/prompt/menu). - [Display QR Code on Device](https://docs.nmi.com/reference/display-device-qr-code-v5.md): Display a QR code on a cloud device screen. - [Cancel Display on Device](https://docs.nmi.com/reference/cancel-device-display-v5.md): Cancel any active display (e.g., QR code) on a cloud device. - [Create Sale Payment Request on Device](https://docs.nmi.com/reference/create-device-payment-request-sale-v5.md): Initiate an asynchronous sale payment request on a specific cloud device. The device_id is specified in the URL path. Payment details (card number, expiration, CVV) are collected by the device itself, so they should not be included in the request body. This endpoint always operates in asynchronous mode. For synchronous payment processing with a device, use POST /api/v5/payments/sale with device_id in the request body. This endpoint uses the same underlying functionality as POST /api/v5/payments/sale. - [Create Authorization Payment Request on Device](https://docs.nmi.com/reference/create-device-payment-request-auth-v5.md): Initiate an asynchronous authorization payment request on a specific cloud device. The device_id is specified in the URL path. Payment details (card number, expiration, CVV) are collected by the device itself, so they should not be included in the request body. This endpoint always operates in asynchronous mode. For synchronous payment processing with a device, use POST /api/v5/payments/auth with device_id in the request body. This endpoint uses the same underlying functionality as POST /api/v5/payments/auth. - [Create Credit Payment Request on Device](https://docs.nmi.com/reference/create-device-payment-request-credit-v5.md): Initiate an asynchronous credit (refund) payment request on a specific cloud device. The device_id is specified in the URL path. Payment details (card number, expiration, CVV) are collected by the device itself, so they should not be included in the request body. This endpoint always operates in asynchronous mode. For synchronous payment processing with a device, use POST /api/v5/payments/credit with device_id in the request body. This endpoint uses the same underlying functionality as POST /api/v5/payments/credit. - [Create Validation Payment Request on Device](https://docs.nmi.com/reference/create-device-payment-request-validate-v5.md): Initiate an asynchronous validation payment request on a specific cloud device. The device_id is specified in the URL path. Payment details (card number, expiration, CVV) are collected by the device itself, so they should not be included in the request body. This endpoint always operates in asynchronous mode. For synchronous payment processing with a device, use POST /api/v5/payments/validate with device_id in the request body. This endpoint uses the same underlying functionality as POST /api/v5/payments/validate. - [Get Payment Request Status](https://docs.nmi.com/reference/get-device-payment-request-status-v5.md): Retrieve the status of an asynchronous payment request initiated on a cloud device. The request_id is obtained from the initial payment request response (e.g., from POST /api/v5/devices/{deviceId}/payment-requests/sale). The device_id must match the device that initiated the payment request. This endpoint uses the same underlying functionality as GET /api/asyncstatus. - [Overview](https://docs.nmi.com/reference/nmi-gateway-features.md) - [Get Sub-Affiliate List](https://docs.nmi.com/reference/get-sub-affiliate-list.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account.
Usage This is a query to get all sub-affiliate accounts under your partner account.
- [Create Merchant](https://docs.nmi.com/reference/create-merchant.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account.
Usage This step simply creates the merchant account, getting their basic information into the gateway. After this step, you can add processors and value-added services before sending the welcome email to the merchant. Note - you can board merchants under an existing sub-affiliate by providing a `parentAffiliateId` in the create request. This will add the merchant under the specified affiliate instead of the account making the request.
- [Assign Fee Schedule to Merchant / Complete and Send Welcome Email / Agree to TOS and Fees for a Merchant](https://docs.nmi.com/reference/patch_v4-merchants-gateway-id-1.md): > **❗️ Never Use Real API Keys** > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account. - [Get a Specific Merchant's Information](https://docs.nmi.com/reference/get-specific-merchant-information.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account.
Usage

This request will return all the details of a specific merchant account. If you need to get multiple merchants' info at once, use the Get Merchant List request.

- [Get Merchant List](https://docs.nmi.com/reference/get-merchant-list.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account.
Usage This is a query to get all merchant accounts under your partner account.
- [Get Settlement Time](https://docs.nmi.com/reference/get-settlement-time.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account.
Usage Use this request to get the settlementTime that is currently set on an existing account. You will see the result at the bottom of the response, in Universal Time Coordinated (UTC). Note - settlement time null represents the default settlement time.
- [Updating Settlement Time](https://docs.nmi.com/reference/updating-settlement-time.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account.
Usage This can be done when creating the merchant’s processor in the first place (Add Processors) but you can also update it whenever you’d like using the request below. Please note this is a PATCH request. Attempting a POST will result in an error. The date must be a valid ISO 8601 time string (Example: 13:14:15). Since this is an update to an existing merchant’s processor, we return the processor object, and you can confirm your change was successful by looking at the settlementTime value in this response.
- [Pull All Fee Schedules](https://docs.nmi.com/reference/pull-all-fee-schedules.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account.
Usage This request will pull all fee schedules available on your account.
- [Get Fees Inside a Fee Schedule](https://docs.nmi.com/reference/get-fees-in-schedule.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account.
Usage Use this request to get a full list of all fees currently set on an existing fee schedule.
- [Add Processor / Value-Added Service](https://docs.nmi.com/reference/add-processor-service.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account.
Adding the Processor This request submits the processor details for a specific merchant.
Add Value-Added Services Value-added services (like Customer Vault) are added the same way as card/check processors, but they are far simpler requests. Each VAS should be added in its own request, so if you wanted to make Customer Vault active, Invoicing active, and Mobile Payments offered, that would be 3 API requests to the `/api/v4/processors` endpoint. ### Service ID Table `serviceId` will vary based on which service you’re trying to add. These are based on which services are available in your estate. | Service | serviceId Value | Additional Details Required? | |:-----------------------------------------|:----------------:|-----------------------------:| | Airline Industry | airline | No | | Automatic Card Updater | acu | Yes | | CardinalCommerce Centinel 3-D Secure 2.0 | centinl2 | Yes | | Customer Vault | vault | No | | Encrypted Devices | magensa | No | | Enhanced Data (Level III) | level3 | No | | Fraud Prevention | isf | No | | Invoicing | invoice | No | | Kount Fraud Manager | kount | No | | Mobile Payments | mobile | No | | Payer Authentication 2.0 | threeds2 | Yes | | QuickBooks SyncPay | qb | No | ### Additional Processor Details A few services allow additional information to configure correctly. These are passed in the `processorFields` object.
**Automatic Card Updater**
This is optional, but passing the `processorFields` object will let you configure ACU to run the first day after the service is activated. You can skip the whole `processorFields` object if you don’t want it to run immediately. ```javascript { "condition": "offered", "status": "active", "serviceId": "acu", "processorFields": { "14": "run_immediately" }, "merchantId": "{{gateway_id}}" } ```
**CardinalCommerce Centinel 3-D Secure 2.0**
Query the service using `/api/v4/services/centinl2/config` for the service for the details of the required fields.
**Payer Authentication 2.0**
Query the service using `/api/v4/services/threeds2/config` for the service for the details of the required fields. ### Request to Make Service Active All fields are required, and it’s the `status` variable that’s telling this to be active right away. The `serviceId` value can be acquired using the `/api/v4/services/search` [documented here](checkservices). As seen in the response, value-added services are technically “processors” so they return many values that you also see when adding a credit card processor, but most of this is not useful info for VAS. Important values here include: * `id` is the unique identifier for this instance of the service * `serviceId` is the code name for the service * `status` will show “pending” until the merchant agrees to the fees/TOS, then it will be “active” * `condition` will always be “offered” even after the merchant signs up ### Request to Make Service Offered The only real difference is that in the response the `status` is now “inactive”.
Cash Processor Overview The “cash processor” provides the same basic functionality as a credit card or check processor, but simply documents transactions instead of “authorizing” them though a payment processor. This means that requests directed to the “cash processor” don’t require any bank account or credit card information. Cash processors have several simplifications compared to credit card and electronic check processors when they are configured. Cash processors: * Do not support duplicate checking. * Do not support monthly or per-transaction limits. * Do not support any “processor information” fields or merchant category codes. For the merchant, the cash processor has certain interface differences from other processors: * Only sale, refund and credit transactions are available on cash processors. * Cash transactions can not be saved to the Customer Vault since there is no sensitive information in the transaction information. * Recurring does not support cash as a payment method for subscriptions. * Invoicing only supports cash payments when manually charging an invoice in the merchant control panel. Customers will not be able to select cash when paying through the payment link they are emailed.
- [Get Merchant Processors and Value Added Services Details](https://docs.nmi.com/reference/get-merchant-processors-value-added-services.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account.
Usage This request will return all services that are active, offered, or in a free trial state for a merchant, or a list of merchants. This will return every detail you can see in the partner portal, so the responses can be quite lengthy if the merchant has several processors and numerous services available to them.
- [Card Type Lookup](https://docs.nmi.com/reference/card-type.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account. Usage This endpoint will return whether the card is a `debit`, `credit`, or `charge` card. A card may return `unknown` if we can't recognize the card type provided. Or it may return `unavailable` if the service is offline. - [Get Processor Config](https://docs.nmi.com/reference/get-processor-config.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account.
Usage This request gets the config details for the processor you want to board. This is required if you do not know what fields to pass into the Add Processor request. You want to include the `id` value from the "Check What Services Are Available" search.
- [Adding Apple Pay to a Merchant](https://docs.nmi.com/reference/adding-apple-pay.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account. This API allows partners to opt their merchants into Apple Pay and allow Collect.js to generate Apple Pay buttons on specific domains for these merchants.
Usage

 

The `gateway_id` in the POST URL refers to the "gateway ID" for the merchant you are updating, so this will change with each new merchant. This is accessible from the Merchant Details page in the partner portal, as well as returned in the Merchant Boarding API when creating a merchant account.

 

The `domains` value is expected to be an array of domains the merchant would like to be allowed to use Apple Pay.

 

> Please be aware that the domains posted to this endpoint should be the full list of domains allowed for this merchant. For example, if you made the same example request again, but only included abc.com as a domain, then example.com and store.acme.com would be removed.
- [Querying A Merchant's Apple Pay Status](https://docs.nmi.com/reference/querying-merchants-apple-pay-status.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account. You may also want to check on the status of Apple Pay for a specific merchant without updating their settings. This is done by making a simple GET request to the same endpoint. > If the merchant has not yet enabled Apple Pay, a `400 Bad Request` response will be returned. - [Get Available Services](https://docs.nmi.com/reference/check-services.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account.
Usage This request will pull down a list of all services that you can offer to merchants. You don’t need to run this every time you board a merchant, but it is useful to occasionally make sure a service is available before trying to add it to a merchant account.
- [Customer Token Vault](https://docs.nmi.com/reference/customer-token-vault.md): Onboard a merchant to Customer Token Vault - [Add Token Vault to a Gateway Account](https://docs.nmi.com/reference/add-token-vault.md): Add (or upgrade) Customer Token Vault to a gateway account. - [Query API](https://docs.nmi.com/reference/query.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account.
Methodology **Overview** While our online reporting interface allows merchants to quickly and easily retrieve detailed information about past transactions, a need for additional flexibility may be required. For example, a merchant may have custom accounting software that requires up-to-date information about the settlement status of all credit card transactions every day. This document describes how developers can query our reporting engine directly to retrieve transaction reports in a machine readable format. Once the data has been retrieved, it can then be parsed and imported into a variety of software applications. **Communication** The communication protocol used to send messages to the Payment Gateway is through the HTTP protocol over an SSL connection (HTTPS). The format you must use is name/value pairs delimited by ampersand. | URL | Example Post Data | |:----------------------------------------|:------------------------------------------------------| | `https://sandbox.nmi.com/api/query.php` | `security_key=security_key&transaction_id=123456789` | You should POST your request to the Query API. The name/value pairs that are accepted by the Payment Gateway can be found in the 'Variables' section of this API. The Query API can be tested with live credentials or a dedicated test account only. Please contact your Merchant Service Provider for more information. The Query API will respond in Universal Time Coordinated (UTC).
Example Response **Query with no report_type or report_type "transaction"** ```xml 2612675976 cc complete 1234567890 123456 John Smith 123 Main St Apt B New York City NY 10001 US johnsmith@example.com 1234567890 1.00 4xxxxxxxxxxx1111 f6c609e195d9d4c185dcc8ca662f0180 1215 N M processora 1.00 USD Keyed 411111 visa iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAIAAACQkWg2AAAAAXNSR0IArs4c6QAAAARnQU1BAA Cxjwv8YQUAAAAJcEhZcwAAEnQA ABJ0Ad5mH3gAAACGSURBVDhPlZGBEoAgCEO1//9nG83mxMrr3dkBG0hVW2vFqLX26CYbPIc7yS AVe8LBq5u4elyV4M0NXIoGXYqA w4QqMAwJCRu+Az7HSlvgHtexlFKwGrLjG/h/rESmhrhRnLCKwjiNeLYv5QsXOoNSig8IsNYaZ0 tXJoGU9hU1k18XlZLOQHTenf7I cf3BwAAAABJRU5ErkJggg== RS-100 1.0000 Red Shirt 10.0000 11.00 sale 20150312215205 1 1.1.1.1 virtual_terminal demo SUCCESS 0 100 NO MATCH 00 11.00 11.00 level3 20150312215205 1 1.1.1.1 virtual_terminal demo 0 100 11.00 settle 20150313171503 1 internal ACCEPTED 76158269 782 100 0000000000021980 ```
Example Response With Processor Details **Query with report_type "profile" and processor_details "true"** ```xml false false Test Company johnsmith@example.com 123-456-7890 123 Fake St Beverly Hills CA 90210 US America/New_York (GMT-05:00) Eastern Time (US & Canada) Visa,Mastercard,American Express,Discover,Diner's Club,JCB,Maestro,Banco Popular,Isracard,Hipercard,Credomatic Card,EBT Test Reseller johnsmith@example.com 123-456-7890 36175F F1577B 26CC9D iVBORw0KGgoAAAANSUhEUgAAALQAAAC0CAMAAAAKE/YAAAAABGdBTUEAALGPC/xhBQAAAAFzUkdCAK7OHOkAAACfUExURUdwTPX19fX19fb29vn5+fX19fX19fb29vX19fX19fb29vb29v////b29vX19f////n5+fX19fn5+fX19ff39/X19fb29vX19fb29vX19f////X19fX19fb29vX19fb29vX19fX19fb29mRkZBcXF/X19e7u7hsbGx8fH0dHR8rKytjY2IWFhb6+vqysrDk5OTg4OFBQUCgoKCEhISIiIjOJ5RMAAAAjdFJOUwD83x8tUeeStfk9rAbl7w8wzDHsINJ82Y42CcFnf/0/9v4+JiMvSAAAAqRJREFUeNrt3dlSwkAUBNBhkSTsyCqr4lyRffP/v81dS0wmQCnc1u5Hn85DhAxV022MK+1ht+XXk9VATpSgmqz7re6wbY7MVa9zMuw3fKd3dbi41mjKmdNs1A4iX+b6oiD93OXe5LIvauKX9yKXvIQoSsIrxZsvMqIsmYsYct4ThfHyLnOqIipTSUWb0wVRmkI6ypwtitoUsxHma1Gc61B1uiiqUwx5QlIFUZ7Ct//GfEXUp7L7yecJQLyd70GByJfvxlIGA50poT0cOw9IOYGCTny+qfoCE//jnCJAeT/L5JDQubcz7A0Suv962m0IVBov6CYWuvnym4yA5flXnB4auveE7qChO8a0AzR00DYDgcvAdPHQXdPCQ7eQXpY+X5rqeOi6SeKhk6aKh66aiI/pyWy92tpzZrtazybhH9Qm9M+LpdWR5SKMF4aejq2ejKd7oecbqymb+R7o+cjqymgei55urLZspnHosdWXcQx6YTVm4UYvVaKXTvTE6szEhZ4pRc9c6LVS9NqFXilFr1zorVL01oW2WkM00Uei77XGhb7VGqKJJppoookmmmiiiSaaaKKJJloTeqQ1/FmMaKKJJppoookm+qfQd78aookmmmiiiSaaaKKJ/ttonlyIJhrgYEs00UQTTTTR/wPNdw+iMS6cPfy5q32Qlyghr6tCXgyGvIKNedkdslYAs8ABsioDs5QEs/4Fs2hHe6VRJFp1TIBnDjBruiAL0SCr5yBL/iDrFCGLKwErQoeYZayQtbeYBcOQVc6QpdmY9eSQRfCQlfuY4waQMxKYgx2Q0yiYIzSQcz+Yw0qYE1aQY2GYs2yYA3iYU4OYo46Y85mYQ6WYk7Cg47uYM8evg9Iqzo2HDEqDTneDjqS/zdEPzjNHP3DP0T8C4oBc15g2YiAAAAAASUVORK5CYII= active false ```
- [Get Transaction Data](https://docs.nmi.com/reference/get-transaction-data.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account.
Usage This is a query to find live transactions by merchants under your partner account. The query will respond in Universal Time Coordinated (UTC). If you provide a specific transaction id, then it will return that transaction. If you provide a sub-affiliates' merchant id in the merchant id list, it will return that merchant's transactions.
- [See Merchants' Billing](https://docs.nmi.com/reference/see-merchant-billing.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account.
Usage This will let you see what billing has occurred on merchants under your partner account. Billing reports are for Bill to Affiliate partners only. For Bill to Merchant partners, you will likely want commission and bill to me reports.
- [See Your Commission](https://docs.nmi.com/reference/see-your-commission.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account.
Usage This will let you see what billing has occurred on merchants under your partner account
- [Get Merchant or Partner User Info](https://docs.nmi.com/reference/get-merchant-partner-user-info.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account.
Usage This will return information on all users associated with a specific merchant or sub-affiliate account.
- [Username Availability](https://docs.nmi.com/reference/check-username-availability.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account.
Usage This is optional, but you can check to make sure a username is available before submitting your merchant creation request.

This can be useful if you want to do form validation on your website to prevent the user from entering a username that has already been taken.
- [Create Merchant API Keys](https://docs.nmi.com/reference/create-merchant-key.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account.
Usage This request will create a new API key for a user on a merchant account. The request includes all key types, including those for the Payment API, Query API, Collect.js, and Collect Checkout.
Sending User ID The `userId` is optional, and will default to the primary user on the account if it is not provided. A full list of user IDs on merchant accounts can be queried via [Get Merchant or Partner User Info](getmerchantorpartneruserinfo).
- [Overview](https://docs.nmi.com/reference/overview.md): This page describes the webhook feature and how to set it up. - [Retry Logic](https://docs.nmi.com/reference/retry-logic.md): This page describes the retry logic used by the gateway when delivering webhook notifications. - [Transaction Events](https://docs.nmi.com/reference/transaction-events.md): Here you can find all the events that are related to transactions. - [Check Status](https://docs.nmi.com/reference/check-status.md): Here you can find all the events that are related to ACH activity - [Recurring Events](https://docs.nmi.com/reference/recurring-events.md): Here you can find all the events that are related to recurring activity. - [Settlement Events](https://docs.nmi.com/reference/settlement-events.md): Here you can find all the events that are related to settlement activity. - [Chargeback Events](https://docs.nmi.com/reference/chargeback-events.md): Here you can find all the events that are related to chargeback activity. - [Automatic Card Updater Events](https://docs.nmi.com/reference/acu-events.md): Here you can find all the events that are related to automatic card updater (ACU) activity. - [Postman Collection](https://docs.nmi.com/reference/postman-collection.md) - [Gateway Emulator](https://docs.nmi.com/reference/gateway-emulator.md) - [MCP](https://docs.nmi.com/reference/mcp.md) - [Transaction Processing](https://docs.nmi.com/reference/transactions-processing.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account.
Methodology **Steps:** 1. The customer sends their payment information to the merchant's web site. 2. The merchant web site posts the payment data to the Payment Gateway. 3. The Payment Gateway responds immediately with the results of the transactions. 4. The merchant web site displays the appropriate message to the customer. The communication method used to send messages to the Payment Gateway's server is the standard HTTP protocol over an SSL connection. In the Payment API method, the communications with the cardholder (Steps 1 and 4) are developed completely by the merchant and therefore are not defined by the Payment Gateway. Step 1 should simply collect the payment data from the cardholder and Step 4 should display the appropriate transaction receipt or declined message. In Step 2, transaction details should be delivered to the Payment Gateway using the POST method with the appropriate variables defined below posted along with the request. In Step 3, the transaction responses are returned in the body of the HTTP response in a query string name/value format delimited by ampersands. For example: `variable1=value1&variable2=value2&variable3=value3` ### Customer Vault The Customer Vault was designed specifically for businesses of any size to address concerns about handling customer payment information. Visa and MasterCard have instituted the Payment Card Industry (PCI) Data Security to protect cardholder data, wherever it resides, ensuring that members, merchants, and service providers maintain the highest information security standards. These associations have also deemed that merchants will be held liable for any breach of cardholder data. This has become a major concern for merchants who handle credit card or electronic check payments. The Customer Vault is designed for these merchants who desire to avoid the tremendous costs and resources involved in becoming PCI compliant under these circumstances. The Customer Vault does this by allowing merchants to transmit their payment information through a Secure Sockets Layer (SSL) connection for storage in our Level 1 PCI certified data facility. Once the customer record has been securely transmitted to the Customer Vault, the merchant can then initiate transactions remotely without having to access cardholder information directly. This process is accomplished without the merchant storing the customer's payment information in their local database or payment application.
Response Code Table | Code | Description | |:------|:-------------------------------------------------------------------| | 100 | Transaction was approved. | | 200 | Transaction was declined by processor. | | 201 | Do not honor. | | 202 | Insufficient funds. | | 203 | Over limit. | | 204 | Transaction not allowed. | | 220 | Incorrect payment information. | | 221 | No such card issuer. | | 222 | No card number on file with issuer. | | 223 | Expired card. | | 224 | Invalid expiration date. | | 225 | Invalid card security code. | | 226 | Invalid PIN. | | 240 | Call issuer for further information. | | 250 | Pick up card. | | 251 | Lost card. | | 252 | Stolen card. | | 253 | Fraudulent card. | | 260 | Declined with further instructions available. (See response text) | | 261 | Declined-Stop all recurring payments. | | 262 | Declined-Stop this recurring program. | | 263 | Declined-Update cardholder data available. | | 264 | Declined-Retry in a few days. | | 300 | Transaction was rejected by gateway. | | 400 | Transaction error returned by processor. | | 410 | Invalid merchant configuration. | | 411 | Merchant account is inactive. | | 420 | Communication error. | | 421 | Communication error with issuer. | | 430 | Duplicate transaction at processor. | | 440 | Processor format error. | | 441 | Invalid transaction information. | | 460 | Processor feature not available. | | 461 | Unsupported card type. |
- [Invoice Management](https://docs.nmi.com/reference/invoices-management.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account.
Methodology **Steps:** 1. The customer sends their payment information to the merchant's web site. 2. The merchant web site posts the payment data to the Payment Gateway. 3. The Payment Gateway responds immediately with the results of the transactions. 4. The merchant web site displays the appropriate message to the customer. The communication method used to send messages to the Payment Gateway's server is the standard HTTP protocol over an SSL connection. In the Payment API method, the communications with the cardholder (Steps 1 and 4) are developed completely by the merchant and therefore are not defined by the Payment Gateway. Step 1 should simply collect the payment data from the cardholder and Step 4 should display the appropriate transaction receipt or declined message. In Step 2, transaction details should be delivered to the Payment Gateway using the POST method with the appropriate variables defined below posted along with the request. In Step 3, the transaction responses are returned in the body of the HTTP response in a query string name/value format delimited by ampersands. For example: `variable1=value1&variable2=value2&variable3=value3` ### Customer Vault The Customer Vault was designed specifically for businesses of any size to address concerns about handling customer payment information. Visa and MasterCard have instituted the Payment Card Industry (PCI) Data Security to protect cardholder data, wherever it resides, ensuring that members, merchants, and service providers maintain the highest information security standards. These associations have also deemed that merchants will be held liable for any breach of cardholder data. This has become a major concern for merchants who handle credit card or electronic check payments. The Customer Vault is designed for these merchants who desire to avoid the tremendous costs and resources involved in becoming PCI compliant under these circumstances. The Customer Vault does this by allowing merchants to transmit their payment information through a Secure Sockets Layer (SSL) connection for storage in our Level 1 PCI certified data facility. Once the customer record has been securely transmitted to the Customer Vault, the merchant can then initiate transactions remotely without having to access cardholder information directly. This process is accomplished without the merchant storing the customer's payment information in their local database or payment application.
Click to see invoice related notes **Update Invoice** All variables (besides currency) on an invoice may be updated. Updating an invoice will not result in a new invoice being sent to the customer. **Send Invoice** To send the invoice after updating an invoice, use the send_invoice request after making changes.
Response Code Table | Code | Description | |:------|:-------------------------------------------------------------------| | 100 | Transaction was approved. | | 200 | Transaction was declined by processor. | | 201 | Do not honor. | | 202 | Insufficient funds. | | 203 | Over limit. | | 204 | Transaction not allowed. | | 220 | Incorrect payment information. | | 221 | No such card issuer. | | 222 | No card number on file with issuer. | | 223 | Expired card. | | 224 | Invalid expiration date. | | 225 | Invalid card security code. | | 226 | Invalid PIN. | | 240 | Call issuer for further information. | | 250 | Pick up card. | | 251 | Lost card. | | 252 | Stolen card. | | 253 | Fraudulent card. | | 260 | Declined with further instructions available. (See response text) | | 261 | Declined-Stop all recurring payments. | | 262 | Declined-Stop this recurring program. | | 263 | Declined-Update cardholder data available. | | 264 | Declined-Retry in a few days. | | 300 | Transaction was rejected by gateway. | | 400 | Transaction error returned by processor. | | 410 | Invalid merchant configuration. | | 411 | Merchant account is inactive. | | 420 | Communication error. | | 421 | Communication error with issuer. | | 430 | Duplicate transaction at processor. | | 440 | Processor format error. | | 441 | Invalid transaction information. | | 460 | Processor feature not available. | | 461 | Unsupported card type. |
- [Subscription Management](https://docs.nmi.com/reference/subscriptions-management.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account.
Methodology **Steps:** 1. The customer sends their payment information to the merchant's web site. 2. The merchant web site posts the payment data to the Payment Gateway. 3. The Payment Gateway responds immediately with the results of the transactions. 4. The merchant web site displays the appropriate message to the customer. The communication method used to send messages to the Payment Gateway's server is the standard HTTP protocol over an SSL connection. In the Payment API method, the communications with the cardholder (Steps 1 and 4) are developed completely by the merchant and therefore are not defined by the Payment Gateway. Step 1 should simply collect the payment data from the cardholder and Step 4 should display the appropriate transaction receipt or declined message. In Step 2, transaction details should be delivered to the Payment Gateway using the POST method with the appropriate variables defined below posted along with the request. In Step 3, the transaction responses are returned in the body of the HTTP response in a query string name/value format delimited by ampersands. For example: `variable1=value1&variable2=value2&variable3=value3` ### Customer Vault The Customer Vault was designed specifically for businesses of any size to address concerns about handling customer payment information. Visa and MasterCard have instituted the Payment Card Industry (PCI) Data Security to protect cardholder data, wherever it resides, ensuring that members, merchants, and service providers maintain the highest information security standards. These associations have also deemed that merchants will be held liable for any breach of cardholder data. This has become a major concern for merchants who handle credit card or electronic check payments. The Customer Vault is designed for these merchants who desire to avoid the tremendous costs and resources involved in becoming PCI compliant under these circumstances. The Customer Vault does this by allowing merchants to transmit their payment information through a Secure Sockets Layer (SSL) connection for storage in our Level 1 PCI certified data facility. Once the customer record has been securely transmitted to the Customer Vault, the merchant can then initiate transactions remotely without having to access cardholder information directly. This process is accomplished without the merchant storing the customer's payment information in their local database or payment application.
Response Code Table | Code | Description | |:------|:-------------------------------------------------------------------| | 100 | Transaction was approved. | | 200 | Transaction was declined by processor. | | 201 | Do not honor. | | 202 | Insufficient funds. | | 203 | Over limit. | | 204 | Transaction not allowed. | | 220 | Incorrect payment information. | | 221 | No such card issuer. | | 222 | No card number on file with issuer. | | 223 | Expired card. | | 224 | Invalid expiration date. | | 225 | Invalid card security code. | | 226 | Invalid PIN. | | 240 | Call issuer for further information. | | 250 | Pick up card. | | 251 | Lost card. | | 252 | Stolen card. | | 253 | Fraudulent card. | | 260 | Declined with further instructions available. (See response text) | | 261 | Declined-Stop all recurring payments. | | 262 | Declined-Stop this recurring program. | | 263 | Declined-Update cardholder data available. | | 264 | Declined-Retry in a few days. | | 300 | Transaction was rejected by gateway. | | 400 | Transaction error returned by processor. | | 410 | Invalid merchant configuration. | | 411 | Merchant account is inactive. | | 420 | Communication error. | | 421 | Communication error with issuer. | | 430 | Duplicate transaction at processor. | | 440 | Processor format error. | | 441 | Invalid transaction information. | | 460 | Processor feature not available. | | 461 | Unsupported card type. |
- [Plan Management](https://docs.nmi.com/reference/plans-management.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account.
Methodology **Steps:** 1. The customer sends their payment information to the merchant's web site. 2. The merchant web site posts the payment data to the Payment Gateway. 3. The Payment Gateway responds immediately with the results of the transactions. 4. The merchant web site displays the appropriate message to the customer. The communication method used to send messages to the Payment Gateway's server is the standard HTTP protocol over an SSL connection. In the Payment API method, the communications with the cardholder (Steps 1 and 4) are developed completely by the merchant and therefore are not defined by the Payment Gateway. Step 1 should simply collect the payment data from the cardholder and Step 4 should display the appropriate transaction receipt or declined message. In Step 2, transaction details should be delivered to the Payment Gateway using the POST method with the appropriate variables defined below posted along with the request. In Step 3, the transaction responses are returned in the body of the HTTP response in a query string name/value format delimited by ampersands. For example: `variable1=value1&variable2=value2&variable3=value3` ### Customer Vault The Customer Vault was designed specifically for businesses of any size to address concerns about handling customer payment information. Visa and MasterCard have instituted the Payment Card Industry (PCI) Data Security to protect cardholder data, wherever it resides, ensuring that members, merchants, and service providers maintain the highest information security standards. These associations have also deemed that merchants will be held liable for any breach of cardholder data. This has become a major concern for merchants who handle credit card or electronic check payments. The Customer Vault is designed for these merchants who desire to avoid the tremendous costs and resources involved in becoming PCI compliant under these circumstances. The Customer Vault does this by allowing merchants to transmit their payment information through a Secure Sockets Layer (SSL) connection for storage in our Level 1 PCI certified data facility. Once the customer record has been securely transmitted to the Customer Vault, the merchant can then initiate transactions remotely without having to access cardholder information directly. This process is accomplished without the merchant storing the customer's payment information in their local database or payment application.
Response Code Table | Code | Description | |:------|:-------------------------------------------------------------------| | 100 | Transaction was approved. | | 200 | Transaction was declined by processor. | | 201 | Do not honor. | | 202 | Insufficient funds. | | 203 | Over limit. | | 204 | Transaction not allowed. | | 220 | Incorrect payment information. | | 221 | No such card issuer. | | 222 | No card number on file with issuer. | | 223 | Expired card. | | 224 | Invalid expiration date. | | 225 | Invalid card security code. | | 226 | Invalid PIN. | | 240 | Call issuer for further information. | | 250 | Pick up card. | | 251 | Lost card. | | 252 | Stolen card. | | 253 | Fraudulent card. | | 260 | Declined with further instructions available. (See response text) | | 261 | Declined-Stop all recurring payments. | | 262 | Declined-Stop this recurring program. | | 263 | Declined-Update cardholder data available. | | 264 | Declined-Retry in a few days. | | 300 | Transaction was rejected by gateway. | | 400 | Transaction error returned by processor. | | 410 | Invalid merchant configuration. | | 411 | Merchant account is inactive. | | 420 | Communication error. | | 421 | Communication error with issuer. | | 430 | Duplicate transaction at processor. | | 440 | Processor format error. | | 441 | Invalid transaction information. | | 460 | Processor feature not available. | | 461 | Unsupported card type. |
- [Customer Management](https://docs.nmi.com/reference/customers-management.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account.
Methodology **Steps:** 1. The customer sends their payment information to the merchant's web site. 2. The merchant web site posts the payment data to the Payment Gateway. 3. The Payment Gateway responds immediately with the results of the transactions. 4. The merchant web site displays the appropriate message to the customer. The communication method used to send messages to the Payment Gateway's server is the standard HTTP protocol over an SSL connection. In the Payment API method, the communications with the cardholder (Steps 1 and 4) are developed completely by the merchant and therefore are not defined by the Payment Gateway. Step 1 should simply collect the payment data from the cardholder and Step 4 should display the appropriate transaction receipt or declined message. In Step 2, transaction details should be delivered to the Payment Gateway using the POST method with the appropriate variables defined below posted along with the request. In Step 3, the transaction responses are returned in the body of the HTTP response in a query string name/value format delimited by ampersands. For example: `variable1=value1&variable2=value2&variable3=value3` ### Customer Vault The Customer Vault was designed specifically for businesses of any size to address concerns about handling customer payment information. Visa and MasterCard have instituted the Payment Card Industry (PCI) Data Security to protect cardholder data, wherever it resides, ensuring that members, merchants, and service providers maintain the highest information security standards. These associations have also deemed that merchants will be held liable for any breach of cardholder data. This has become a major concern for merchants who handle credit card or electronic check payments. The Customer Vault is designed for these merchants who desire to avoid the tremendous costs and resources involved in becoming PCI compliant under these circumstances. The Customer Vault does this by allowing merchants to transmit their payment information through a Secure Sockets Layer (SSL) connection for storage in our Level 1 PCI certified data facility. Once the customer record has been securely transmitted to the Customer Vault, the merchant can then initiate transactions remotely without having to access cardholder information directly. This process is accomplished without the merchant storing the customer's payment information in their local database or payment application.
Response Code Table | Code | Description | |:------|:-------------------------------------------------------------------| | 100 | Transaction was approved. | | 200 | Transaction was declined by processor. | | 201 | Do not honor. | | 202 | Insufficient funds. | | 203 | Over limit. | | 204 | Transaction not allowed. | | 220 | Incorrect payment information. | | 221 | No such card issuer. | | 222 | No card number on file with issuer. | | 223 | Expired card. | | 224 | Invalid expiration date. | | 225 | Invalid card security code. | | 226 | Invalid PIN. | | 240 | Call issuer for further information. | | 250 | Pick up card. | | 251 | Lost card. | | 252 | Stolen card. | | 253 | Fraudulent card. | | 260 | Declined with further instructions available. (See response text) | | 261 | Declined-Stop all recurring payments. | | 262 | Declined-Stop this recurring program. | | 263 | Declined-Update cardholder data available. | | 264 | Declined-Retry in a few days. | | 300 | Transaction was rejected by gateway. | | 400 | Transaction error returned by processor. | | 410 | Invalid merchant configuration. | | 411 | Merchant account is inactive. | | 420 | Communication error. | | 421 | Communication error with issuer. | | 430 | Duplicate transaction at processor. | | 440 | Processor format error. | | 441 | Invalid transaction information. | | 460 | Processor feature not available. | | 461 | Unsupported card type. |
- [Billing Information Management](https://docs.nmi.com/reference/billing-management.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account.
Methodology **Steps:** 1. The customer sends their payment information to the merchant's web site. 2. The merchant web site posts the payment data to the Payment Gateway. 3. The Payment Gateway responds immediately with the results of the transactions. 4. The merchant web site displays the appropriate message to the customer. The communication method used to send messages to the Payment Gateway's server is the standard HTTP protocol over an SSL connection. In the Payment API method, the communications with the cardholder (Steps 1 and 4) are developed completely by the merchant and therefore are not defined by the Payment Gateway. Step 1 should simply collect the payment data from the cardholder and Step 4 should display the appropriate transaction receipt or declined message. In Step 2, transaction details should be delivered to the Payment Gateway using the POST method with the appropriate variables defined below posted along with the request. In Step 3, the transaction responses are returned in the body of the HTTP response in a query string name/value format delimited by ampersands. For example: `variable1=value1&variable2=value2&variable3=value3` ### Customer Vault The Customer Vault was designed specifically for businesses of any size to address concerns about handling customer payment information. Visa and MasterCard have instituted the Payment Card Industry (PCI) Data Security to protect cardholder data, wherever it resides, ensuring that members, merchants, and service providers maintain the highest information security standards. These associations have also deemed that merchants will be held liable for any breach of cardholder data. This has become a major concern for merchants who handle credit card or electronic check payments. The Customer Vault is designed for these merchants who desire to avoid the tremendous costs and resources involved in becoming PCI compliant under these circumstances. The Customer Vault does this by allowing merchants to transmit their payment information through a Secure Sockets Layer (SSL) connection for storage in our Level 1 PCI certified data facility. Once the customer record has been securely transmitted to the Customer Vault, the merchant can then initiate transactions remotely without having to access cardholder information directly. This process is accomplished without the merchant storing the customer's payment information in their local database or payment application.
Response Code Table | Code | Description | |:------|:-------------------------------------------------------------------| | 100 | Transaction was approved. | | 200 | Transaction was declined by processor. | | 201 | Do not honor. | | 202 | Insufficient funds. | | 203 | Over limit. | | 204 | Transaction not allowed. | | 220 | Incorrect payment information. | | 221 | No such card issuer. | | 222 | No card number on file with issuer. | | 223 | Expired card. | | 224 | Invalid expiration date. | | 225 | Invalid card security code. | | 226 | Invalid PIN. | | 240 | Call issuer for further information. | | 250 | Pick up card. | | 251 | Lost card. | | 252 | Stolen card. | | 253 | Fraudulent card. | | 260 | Declined with further instructions available. (See response text) | | 261 | Declined-Stop all recurring payments. | | 262 | Declined-Stop this recurring program. | | 263 | Declined-Update cardholder data available. | | 264 | Declined-Retry in a few days. | | 300 | Transaction was rejected by gateway. | | 400 | Transaction error returned by processor. | | 410 | Invalid merchant configuration. | | 411 | Merchant account is inactive. | | 420 | Communication error. | | 421 | Communication error with issuer. | | 430 | Duplicate transaction at processor. | | 440 | Processor format error. | | 441 | Invalid transaction information. | | 460 | Processor feature not available. | | 461 | Unsupported card type. |
- [Product Management](https://docs.nmi.com/reference/products-management.md): > ❗️ Never Use Real API Keys > > Never use real API Keys when testing. The gateway allows Partners to create Test Merchant Accounts. Testing should always use keys from the Test Accounts and never keys from a Standard Account.
Methodology **Steps:** 1. The customer sends their payment information to the merchant's web site. 2. The merchant web site posts the payment data to the Payment Gateway. 3. The Payment Gateway responds immediately with the results of the transactions. 4. The merchant web site displays the appropriate message to the customer. The communication method used to send messages to the Payment Gateway's server is the standard HTTP protocol over an SSL connection. In the Payment API method, the communications with the cardholder (Steps 1 and 4) are developed completely by the merchant and therefore are not defined by the Payment Gateway. Step 1 should simply collect the payment data from the cardholder and Step 4 should display the appropriate transaction receipt or declined message. In Step 2, transaction details should be delivered to the Payment Gateway using the POST method with the appropriate variables defined below posted along with the request. In Step 3, the transaction responses are returned in the body of the HTTP response in a query string name/value format delimited by ampersands. For example: `variable1=value1&variable2=value2&variable3=value3` ### Customer Vault The Customer Vault was designed specifically for businesses of any size to address concerns about handling customer payment information. Visa and MasterCard have instituted the Payment Card Industry (PCI) Data Security to protect cardholder data, wherever it resides, ensuring that members, merchants, and service providers maintain the highest information security standards. These associations have also deemed that merchants will be held liable for any breach of cardholder data. This has become a major concern for merchants who handle credit card or electronic check payments. The Customer Vault is designed for these merchants who desire to avoid the tremendous costs and resources involved in becoming PCI compliant under these circumstances. The Customer Vault does this by allowing merchants to transmit their payment information through a Secure Sockets Layer (SSL) connection for storage in our Level 1 PCI certified data facility. Once the customer record has been securely transmitted to the Customer Vault, the merchant can then initiate transactions remotely without having to access cardholder information directly. This process is accomplished without the merchant storing the customer's payment information in their local database or payment application.
Response Code Table | Code | Description | |:------|:-------------------------------------------------------------------| | 100 | Transaction was approved. | | 200 | Transaction was declined by processor. | | 201 | Do not honor. | | 202 | Insufficient funds. | | 203 | Over limit. | | 204 | Transaction not allowed. | | 220 | Incorrect payment information. | | 221 | No such card issuer. | | 222 | No card number on file with issuer. | | 223 | Expired card. | | 224 | Invalid expiration date. | | 225 | Invalid card security code. | | 226 | Invalid PIN. | | 240 | Call issuer for further information. | | 250 | Pick up card. | | 251 | Lost card. | | 252 | Stolen card. | | 253 | Fraudulent card. | | 260 | Declined with further instructions available. (See response text) | | 261 | Declined-Stop all recurring payments. | | 262 | Declined-Stop this recurring program. | | 263 | Declined-Update cardholder data available. | | 264 | Declined-Retry in a few days. | | 300 | Transaction was rejected by gateway. | | 400 | Transaction error returned by processor. | | 410 | Invalid merchant configuration. | | 411 | Merchant account is inactive. | | 420 | Communication error. | | 421 | Communication error with issuer. | | 430 | Duplicate transaction at processor. | | 440 | Processor format error. | | 441 | Invalid transaction information. | | 460 | Processor feature not available. | | 461 | Unsupported card type. |
## Recipes - [Activate Merchant & Send Welcome Email](https://docs.nmi.com/recipes/activate-merchant-send-welcome-email.md) - [Authorize and Add to Customer Vault](https://docs.nmi.com/recipes/authorize-and-add-to-customer-vault.md) - [Create Merchant API Keys](https://docs.nmi.com/recipes/create-merchant-api-keys.md) - [Payment Component Frontend](https://docs.nmi.com/recipes/payment-component-frontend.md) - [Recurring Payment](https://docs.nmi.com/recipes/recurring-payment.md) - [Refund Credit Card Transaction](https://docs.nmi.com/recipes/refund-credit-card-transaction.md) - [Sale and Add to Customer Vault](https://docs.nmi.com/recipes/sale-and-add-to-customer-vault.md) - [Sale](https://docs.nmi.com/recipes/sale.md) - [Validate and Add to Customer Vault](https://docs.nmi.com/recipes/validate-and-add-to-customer-vault.md)