Skip to main content

v3 - NMI Integration

NMI payment gateway: online card payments, saved card, in-person payment with a card terminal, pre-authorization/capture and refunds. Step-by-step setup, every field explained, daily use and frequently asked questions.

Index

What is this integration?

The NMI integration connects Golfmanager with the NMI payment gateway. It is one of the most complete payment integrations: it allows online card payments, saving the customer's card for future payments, in-person payment with a card terminal at the POS, pre-authorizations (holding funds) and refunds (full or partial).

NMI is a payment platform many providers operate on. If you work with a provider based on NMI —for example, Fort Point Payments—, the connection with Golfmanager is made through this same NMI module, using the credentials that provider gives you.

What problem does it solve?

  • Take payments across all channels with a single gateway: online, in-person POS and with a saved card.

  • Speeds up the regular customer: they can pay with their saved card without typing it again.

  • Allows holding funds (pre-authorization) and charging them later, useful for deposits/guarantees.

  • Greater security: the card data is handled securely (tokenization); it is not stored in Golfmanager.

Payment modes it offers

Mode

What it is for

Online payment

The customer pays by card when booking or buying online

Saved card

Charge a card the customer saved previously

In-person payment (terminal)

Charge at the POS with an NMI reader/terminal

Pre-authorization and capture

Hold funds and charge them later (or release them)

Refund

Reimburse a sale in full or in part

Which systems does it connect and in which direction does the data flow?

It connects Golfmanager with the NMI gateway in real time:

  • In the online payment, the card is entered in a secure form and NMI returns a token; Golfmanager requests the charge with that token.

  • In the in-person payment, Golfmanager sends the charge to the terminal through NMI and checks the result until the customer presents the card.

  • NMI confirms each operation (payment, pre-authorization, capture or refund) and Golfmanager records it.

🔒 Security: the card data is handled through tokenization with NMI. Golfmanager stores a secure reference (token), not the card number.

Prerequisites (before activating the integration)

  1. Have an NMI account or one with an NMI-based provider (for example, Fort Point Payments).

  2. Have the NMI module installed, together with the bookings, POS and consumer-area modules.

  3. The NMI credentials: API security key, tokenization key (collect.js) and Processor ID.

  4. For in-person payment, an NMI-compatible terminal and its registration code.

  5. Administration/billing permissions to configure.

How to set it up (step by step)

Step 1 — Credentials

  1. Log in to Golfmanager with an administrator user.

  2. Go to NMI > Configuration.

  3. Enter the API Security Key.

  4. Enter the Tokenization key (collect.js).

  5. Enter the Processor ID (you will find it in your NMI portal, under Settings → Transaction Routing).

  6. Save the changes. The keys are stored encrypted.

Step 2 — Terminals (only for in-person payment)

  1. Go to NMI > Payment devices.

  2. Click Add.

  3. Enter the terminal's registration code.

  4. Enter a name to identify it.

  5. Save. The device will become available to charge at the POS.

⚠️ There is no "test/production mode" switch: the environment is determined by the keys themselves. First use the test credentials and data NMI provides to validate the flow and, when everything works, replace them with the real credentials.

Explanation of each field

Below is a description of each field in the integration: where it is, what it means, its impact on the system, and a usage example (what happens when it is used and how the system behaves).

A) Configuration (NMI > Configuration)

1. API Security Key

  • Description: the private key of your NMI account (or your NMI-based provider) with which the Golfmanager server authenticates all operations.

  • Impact on the system: it is mandatory for everything (online, in-person, pre-authorizations and refunds). Stored encrypted. In addition, whether it is a test or production key determines which environment you operate in.

  • Usage example: you copy it from your NMI portal/provider and paste it here.

    • What happens when it is used: it is used on every charge, pre-authorization, capture and refund to authenticate with NMI.

    • System behavior: if it is missing, "The NMI secret key is not configured" (or "NMI is not configured") appears when operating and the operation is not carried out.

2. Tokenization key (collect.js)

  • Description: the public key that loads the secure card form (Collect.js) in the customer's browser.

  • Impact on the system: it is mandatory for online payment; without it, the card form cannot be shown. Stored encrypted.

  • Usage example: you copy it from your NMI portal and paste it here.

    • What happens when it is used: when an online payment starts, the secure form loads with this key and tokenizes the card (turns it into a token).

    • System behavior: if it is missing, "The NMI data tokenization key is not configured" appears.

3. Processor ID

  • Description: the processor identifier in NMI (you will find it under Settings → Transaction Routing in your portal).

  • Impact on the system: it is mandatory for in-person payment (terminal), pre-authorizations and card validation.

  • Usage example: you copy it from your NMI portal and paste it here.

    • What happens when it is used: it is sent in terminal operations to route the charge correctly.

    • System behavior: if it is missing, "The NMI processor ID is not configured" appears.

B) Payment devices (terminals)

4. Device name

  • Description: the name with which you identify the terminal in Golfmanager.

  • Impact on the system: it helps you choose the right terminal when charging (if you have several).

  • Usage example: "Reception terminal" or "Bar terminal".

    • What happens when it is used: it appears in the device list when starting an in-person charge.

    • System behavior: if you leave it empty when registering, "Enter the device name" appears.

5. Registration code

  • Description: the code that links the physical terminal with your NMI account.

  • Impact on the system: required to register the device; without it, the reader is not available to charge.

  • Usage example: you get it from the terminal or the NMI portal and enter it when adding the device.

    • What happens when it is used: after registering it, the terminal becomes available at the POS to charge.

    • System behavior: if it is missing, "Enter the registration code" appears.

C) Payment methods

6. "NMI" (online) and "NMI In Person" (in-person)

  • Description: the two payment means of the integration. NMI is for the customer's online payment (bookings/shop area) and NMI In Person for the in-person charge at the POS with a terminal.

  • Impact on the system: they must be active to be able to charge on each channel. Both support refunds; "NMI In Person" also supports pre-authorization and capture.

  • Usage example: you make sure "NMI" appears at the online checkout and "NMI In Person" at the POS.

    • What happens when it is used: the customer pays online with NMI, or staff charge with a terminal using NMI In Person.

    • System behavior: if the option does not appear, check that the method is active and that the necessary credentials are configured (tokenization for online; Processor ID for in-person).

D) The customer's saved card

7. Saved card (brand, last digits, default card)

  • Description: the tokenized card the customer decides to save. It is shown by its brand and its last 4 digits (for example, "Visa ...4111"); one can be marked as the default card.

  • Impact on the system: it allows charging in the future without typing the card again. Golfmanager stores only a secure reference (token), not the full number.

  • Usage example: these details are not filled in by hand: they are created when the customer ticks "save card" at payment (or when staff tokenize a card).

    • What happens when it is used: on the next payment, the customer (or staff) can choose that saved card to charge.

    • System behavior: if a customer has no cards, trying to use this method shows "The client does not have saved cards". Cards are checked in NMI > Cards.

How to use it day to day (step by step)

Online payment and saved card

  1. The customer makes a booking or a purchase and chooses NMI at payment.

  2. They enter their card in the secure form (or choose a saved card, if they have one).

  3. If they tick "save card", it will be available for future payments.

  4. On approval, the sale is marked as paid.

In-person payment at the POS

  1. At the POS, select "NMI In Person".

  2. Choose the terminal from the list.

  3. The customer taps, inserts or swipes the card on the reader.

  4. Wait for confirmation: Golfmanager checks the result until the charge completes.

Pre-authorization and capture

  1. To hold funds (for example, a guarantee), start a pre-authorization with the terminal.

  2. Later, capture (charge) the relevant amount —it can be partial— or cancel the hold if it no longer applies.

Save a card without charging

  1. Select the customer and the terminal.

  2. Start the card validation (amount 0): the customer presents the card and it is saved for future charges, without charging anything.

Refunds

  1. Open the sale to refund.

  2. Use Options > Discard (or the corresponding refund): Golfmanager sends NMI the refund of the transaction.

  3. Check in Transactions that the refund was recorded.

Partial refunds and several refunds against the same charge are supported (up to the charged amount). Refunds are performed by staff, not the customer.

Transactions, cards and devices

In the NMI menu you have:

  • Transactions (NMI Transactions): the log of all payments, pre-authorizations, captures and refunds, with their result (successful or failed), the amount, the customer and the transaction identifier in NMI.

  • Cards (NMI Cards): the customers' saved cards (brand and last digits).

  • Payment devices: the registered terminals.

Transactions are the first screen to check when a charge has not completed.

Limitations to keep in mind

  • In-person payment requires an NMI-compatible terminal, registered in the module with its registration code.

  • The saved card depends on the customer having agreed to save it (or on staff having tokenized it).

  • In-person payment is asynchronous: the system waits for the customer to present the card on the reader; it may take a few seconds.

  • Refunds require the original NMI transaction; they are performed by staff, not the customer.

  • It depends on an external service: if NMI (or your provider) is unavailable, payments cannot be processed at that moment.

  • You need the correct credentials (API key, tokenization and Processor ID) for the environment you use.

Frequently asked questions

When paying, "NMI is not configured" appears. What does it mean?

Credentials are missing in the configuration. Go to NMI > Configuration and check that the API security key, the tokenization key and the Processor ID are there; complete them and save.

"The NMI secret key is not configured", "The tokenization key…" or "The Processor ID…" appears.

The message indicates exactly which credential is missing. Each one is used for something: the security key for all operations, the tokenization key for the online payment form and the Processor ID for in-person charging. Fill in the missing one in NMI > Configuration.

NMI does not appear as a payment option.

Check that the payment method is active and that the necessary credentials are configured: online payment needs the tokenization key; in-person needs the Processor ID and at least one registered terminal.

No terminal appears when charging in person.

There are no registered devices ("There are no registered payment devices" appears). Go to NMI > Payment devices, click Add and enter the terminal's registration code and a name.

When registering a terminal it asks me for the name or the registration code.

Both are mandatory. "Enter the device name" or "Enter the registration code" appears if either is missing. Complete both and save.

The in-person payment does not complete or keeps waiting.

In-person payment is asynchronous: the system waits for the customer to present the card on the reader. Check that the terminal is on and connected, that the customer taps/inserts the card, and review the detail in Transactions. If the customer cancels at the terminal, you will see "Payment cancelled at terminal".

The customer's card was declined (for example, "Card Declined" or "Insufficient Funds").

It is the response returned by NMI/the bank. Ask the customer to retry or use another card. The exact text (declined, invalid CVV, insufficient funds…) appears in the transaction.

"Error completing the operation. The collection has already been made. Please contact the center." appears.

It is a cautious warning: the charge may have gone through even though the confirmation did not arrive correctly. Before retrying, check in Transactions whether the payment shows as successful, so you don't charge twice. If in doubt, contact support.

The customer does not see their saved card.

It may not have been saved (they did not tick "save card") or it may not be the same customer. Have them pay again ticking "save card", or staff can save it via card validation. If using the method shows "The client does not have saved cards", there is none associated.

How do I save a customer's card without charging them?

With card validation: you select the customer and the terminal, the customer presents the card with amount 0 and it is saved for future charges without charging anything.

What is pre-authorization and what is it for?

It is a hold on funds (without a final charge), useful for guarantees or deposits. Afterwards you can capture (charge) the amount —full or partial— or cancel the hold to release the funds.

Can I capture an amount different from the one pre-authorized?

Yes. When capturing you can indicate the relevant amount (for example, adding a tip or charging less), always within what the pre-authorization allows.

Can partial refunds be made?

Yes. You can refund part of the amount and even make several refunds against the same charge, up to the total charged. The original transaction keeps track of what has already been refunded.

I try to refund and it says the original transaction ID is missing or that I must cancel the original payment.

The refund needs the original NMI transaction. For online payments, the original payment must be cancelled first; if the notice is "Cannot refund: the original NMI transaction id is missing", review the transaction and contact support (it may be an old payment).

How do I work in test before charging for real?

There is no test/production switch: the environment is determined by the keys. Use NMI's test credentials and cards to validate the flow and, when everything works, replace the keys with the production ones.

Does the card data pass through Golfmanager?

No. The card is entered in the secure NMI form (or read on the terminal) and is tokenized. Golfmanager stores only a secure reference (token), never the full number.

I work with an NMI-based provider (such as Fort Point Payments). Which credentials do I use?

The ones that provider gives you: the API security key, the tokenization key and the Processor ID. The connection with Golfmanager is made through this same NMI module.

Where do I see whether a charge failed and why?

In NMI > Transactions. Each operation shows whether it was successful or failed, the amount, the customer, the error detail and the transaction identifier in NMI. It is the first place to look for any issue.

Recommended best practices

  • Test first with NMI's test credentials before operating for real.

  • If you use an NMI-based provider (such as Fort Point Payments), ask them for the API key, the tokenization key and the Processor ID.

  • Use pre-authorization for guarantees/deposits and capture only what applies.

  • Give each terminal a clear name to choose the right one when charging.

  • On a failed charge, check Transactions first: the detail usually indicates the cause.

Did this answer your question?