Payment Processing

Both staff using the Staff View order process and constituents using Community Hub may make a payment using a one-time credit/debit card, stored credit card, or eCheck. For new orders, the checkout process results in the creation of an order in Nimble AMS and the payment gateway is used to process the payment. Nimble AMS stores all of the order details, while the payment gateway handles the actual processing and receipt of payment. For PCI compliance, the constituent's payment details such as full credit card or account number are never stored in Nimble AMS.

Payment Gateways

With Nimble AMS, you can set up one or more payment gateways to process payments for your entity(s) from credit/debit cards and store payment methods in Community Hub and Staff View. Each payment gateway record includes the information needed for Nimble AMS to communicate to a third-party payment gateway.

Learn more.

Credit and Debit Cards

Nimble AMS can process payments from credit and debit cards that have the same logo as of one of your credit card issuers (such as MasterCard® or Visa®); debit cards are processed like credit cards. Just keep in mind that Nimble AMS does not support PIN-based debit card transactions.

Billing Address Verification

You can set your org up to use the billing address when verifying credit cards to provide a more secure and cost-effective credit card verification. Learn more about billing address verification.

Level 2 and Level 3 Credit Card Processing

Credit card payments in Nimble AMS typically include a minimal amount of transaction data that is passed to the payment gateway; this is known as Level 1 (L1) credit card processing. If you are using the BluePay or CardPointe payment gateway, you can use Level 2 (L2) or Level 3 (L3) payment processing to send additional transaction data from Community Hub and Staff View to the payment gateway and lower processing fees for MasterCard® and Visa® transactions.

Learn more about Level 2 and Level 3 credit card processing for Bluepay Payment Gateway.

Learn more about Level 2 and Level 3 credit card processing for CardPointe Payment Gateway.

Hosted Payment Forms

You can set your org up to use the Hosted Payment Forms for making PCI compliance much easier than before, as the credit card data is not captured/stored on the Nimble AMS or Community Hub and is directly entered on the Hosted Payment Forms and handled by the BluePay payment gateway for processing the order payments. Learn more about Hosted Payment Forms.

Note

As of now, Nimble AMS does not support Hosted Payment Forms with CardPointe Payment Gateway Integration.

Stored Payment Methods

Staff and constituents can add stored credit/debit cards or eCheck bank accounts to their account which they can use to check out quickly in the future. When staff or constituents add a new card or eCheck account, the information is verified with the payment gateway to ensure the card number and security code are accurate and the card has not expired or for an eCheck account, the account number is valid. When a new stored payment method is created, a new payment profile is made in a payment gateway and a nominal charge to the account, less than $1, is made temporarily to ensure the payment option is valid and is voided soon after.

To use the billing address when verifying stored credit cards, you will need to activate the service in your payment gateway. Learn more. You will also want to edit the field set used by the card on the Manage Credit Card Page and require all Community Hub billing address fields.

Scheduled Payment Methods

Modifying/Updating details after a schedule has been set up

Please note that the schedule job will pick the schedules where the Number of Retries on the schedule is 'less than or equal to' the Nimble configure 'Number of Retries' setting. After updating the scheduled payment method and setting the schedule status back to pending please also set the Number of Retries on the schedule to less than or equal to the Nimble configure 'Number of Retries' setting.

Immediate Payments

Payments can be entered in both the Staff View order process and in the Community Hub checkout. In both cases, Nimble AMS stores all of the order details, while the payment gateway handles the actual processing and receipt of payment.

How payments are processed is different between Staff View and Community Hub.

Payment Processing in Staff View

Credit card and eCheck processing for payments entered in Staff View is a multi-step process:

Step 1: Staff clicks the Save button on the Payment Details dialog box in the Payment step of the order process.

The cart payment and cart payment lines are created.

Step 2: A callout to the payment gateway is made that captures the funds for payment.

A callout is made to the payment gateway.
For a one-time or stored credit card payment:
- The card payment is authorized, and funds are placed on temporary hold, ensuring the card information is accurate and that there are enough funds for the payment.
- A new transaction is created in the payment gateway with the Captured/Pending Settlement status.
- If you are using the BluePay payment gateway, and the payment was made using a stored payment method, Nimble AMS checks to see if the payment information—such as the last four digits of the credit card number—has been updated. If so, the payment information on the external payment profile representing the stored payment method is updated in Nimble AMS. Learn more about the BluePay Account Updater (external).
- If you are using the BluePay payment gateway with Hosted Payment Forms enabled, and the payment was made using a new credit/debit card, you will enter the card details on the Hosted Payment Forms of the Payment Gateway instead of Nimble AMS.
- The constituent's credit card is charged for the amount of purchase.
- If your association uses Level 2 or Level 3 credit card processing, the additional transaction data is sent to the payment gateway.
For a stored eCheck:
- A new transaction is created in the payment gateway with the Authorized/Pending Capture status.

Step 3: Staff clicks the Submit button in the Payment step of the order process.

An order containing all of the purchased items is available in Nimble AMS. Staff can view the order and see that it has been processed successfully.

Payment Processing in Community Hub

Credit card processing for orders entered in Community Hub follows these steps:

Step 1: The constituent clicks the Checkout button in the Community Hub.

A callout is made to the configured payment gateway:
- For a one-time or stored credit card, the card number and billing address information—if captured on the page—are verified and a check is done to ensure there are enough funds for the payment.
- For a stored eCheck account, the routing number is verified.
A new transaction is created in the payment gateway with the Authorized/Pending Capture status.
If you are using the BluePay payment gateway, and the payment was made using a stored payment method, Nimble AMS checks to see if the payment information—such as the last four digits of the credit card number—has been updated. If so, the payment information on the external payment profile representing the stored payment method is updated in Nimble AMS. Learn more about the BluePay Account Updater (external).
If you are using the BluePay payment gateway with Hosted Payment Forms enabled, and the payment was made using a new credit/debit card, you will enter the card details on the Hosted Payment Forms of the Payment Gateway instead of Community Hub.
In Nimble AMS, a payment, and associated records are created. Pending Capture is selected on the payment and Payment Processor Code and Payment Processor Reason Code are set to 1, indicating the authorization was successful which can be seen in a report.
For a stored payment method, or if the billing address was captured with the one-time credit card information, the billing address fields on the payment are updated.
The card is not yet charged for the full amount of the order.

Step 2: The order submits and is captured and processed in Nimble AMS.

An order containing all of the purchased items is available in Nimble AMS.
If your association uses Level 2 or Level 3 credit card processing, the additional transaction data is sent to the payment gateway.

Step 3: For credit cards, a callout to the payment gateway is made that secures the funds for payment.

When the payment is captured, the payment gateway transaction status is updated to Captured/Pending Settlement.
In Nimble AMS, Pending Capture the payment is deselected.
The constituent's credit card is charged for the amount of purchase.
The constituent can view the order and see that it has been processed successfully.

If an order fails due to lack of inventory or other issues, the amount held in Step 1 is voided. The hold is no longer applied against the card.

Transaction Settlement

To enhance your analytics, Nimble AMS tracks when payments are created and when they are settled.

Payment Date populates with the date the payment is created as part of an order.

The Reconcile Unsettled Payments scheduled job runs each night to reach out to the payment gateway and update any payment record that has been settled. When a payment is settled, Settlement Date is updated with the settlement date. If a payment cannot be found in the payment gateway, Settlement Fail is selected, Settlement Date is left blank, and no further settlement attempts are made.

Secondary Stored Payment Method Updates

If you are using the BluePay payment gateway, and the payment was made using a stored payment method, the Reconcile Unsettled Payments scheduled job double checks to see if the payment information—such as the last four digits of the credit card number—has been updated since the payment transaction was created in the gateway. If so, the payment information on the external payment profile representing the stored payment method is updated in Nimble AMS. Learn more about the BluePay Account Updater (external).

Payment Failures

From time to time, a failure can occur during this process. Often the failure is around step one, in the case where staff or a constituent enters a credit card that cannot be authorized. In the case of any failure, some safeguards are in place to keep your data clean and help identify any payments that could not be processed:

Failure on payment authorization or cart submission (rare) - No records are created in Nimble AMS and the transaction in the payment gateway is canceled.

If you have set up the payment gateway to use the billing address when verifying credit cards, be sure to edit the field set used by the card on the Manage Credit Card Page and require all Community Hub billing address fields.
Failure on payment processing (extremely rare) - The transaction in the payment gateway remains with a status of Authorized/Pending Capture until it expires; typically within 30 days.
In Nimble AMS, Pending Capture on the payment is left selected and Payment Processor Code and Payment Processor Reason Code are set to something other than 1, indicating the payment was not successfully processed which can be seen on a report. For more information, see Transaction Details Guide (external), appendix B. Additionally, the configured administrator for your org is sent an email about the failure with the value of Payment Processor Raw Response from the payment to help diagnose the issue.

Flexible Payments

If you are using flexible payments, the Process Scheduled Payments the scheduled job runs every night to do the processing.

Read a more general overview of Flexible Payments here.

Nimble AMS does not allow the staff user to update the Nimble AMS Product’s status to “Inactive“ if that product is part of an ongoing schedule. A schedule can be the Recurring or the Installment Payments. This restriction applies to both.

One-Time Scheduled and Installment Payments

For schedules with a Record Type of Payment, the Process Scheduled Payments scheduled job makes payment for any child schedule lines if either of the following conditions are met:

Status is Pending and Date is the current date, or
Status is Failed, and Date is in the past, and Number of Retries is less than the Payment Retry Attempts defined in the Nimble AMS package configuration (the default number of retries is four times).

Once processed, a payment record is created and related to the schedule line.

Because flexible payments are made using a stored payment method, the payment is processed in the gateway as a one-time stored payment method payment.

Schedule Line Statuses

Throughout the lifetime of a schedule line, Status progresses through different values, depending on where the schedule line is in the payment process:

Value	Description
Pending	The schedule line has not been processed. This is the initial value of the schedule line when the payment is scheduled.
Processed	The schedule line has successfully been processed.
Failed	The schedule line failed to process. *(see info note below)
Canceled	The schedule line was canceled before being processed.

Schedule lines are only used by one-time scheduled payments and installment payments, which are represented by a schedule with the Record Type of Payment. In other words, schedule lines are not used by recurring payments.

Please note that if someone updates the Schedule line, the Scheduled Payment Method, or Card, this will not affect the number of retries for a failing payment and will NOT successfully process the payment automatically.

Recurring Payments

For schedules with a Record Type of Recurring, the Process Scheduled Payments a scheduled job generates a recurring order if:

Stage is Ongoing and Grand Total on the related Order is 0.

Specifically, the Process Scheduled Payments scheduled job submits a new order with order items containing the recurring eligible products from the initial order. Dates are adjusted for time-sensitive products, products are repriced if configured, and a new payment(s) is made, depending on the payment option selected when recurrence was enabled. If recurrence is set to pay:

immediately with a stored payment method, then the new order includes an immediate payment using the same stored payment method.
as a one-time scheduled payment, then a new payment is scheduled for the same number of days out from the initial order.
in installment payments, then a new schedule with schedule lines is created using the same frequency used on the initial schedule.

Learn more about special product considerations when processing recurring payments in Flexible Payment Details.

Sales Tax

If an order is generated by recurring payments, the total tax will be calculated automatically.

Retrying Failed Flexible Payments

Sometimes flexible payments fail. This can occur, for example, when the scheduled payment amount exceeds the credit limit on a stored credit card or when a recurring order fails to process. In the case of a failure, it can be useful to automatically retry failed scheduled or recurring payments multiple times to reduce the need for manual intervention from staff.

When a scheduled payment fails, Status on the schedule, the line is set to Failed.
When a recurring payment fails, and is retried, Number of Retries the recurring schedule is updated to the number of times the payment is retried. The number of Retries is not incremented when a Schedule Line fails the first time.

By default, Nimble AMS automatically retries submitting a failed scheduled or recurring payment four times. This is determined by the value Payment Retry Attempts defined in the Nimble AMS package configuration.

When the Process Scheduled Payments the scheduled job runs again, it does the following:

Finds any:
1. schedules with a Record Type of Recurring and Stage of Failed.
2. schedule lines with a Status of Failed, and Date in the past, and Number of Retries less than or the same as the configured Payment Retry Attempts.
If it finds any, it attempts to make the payment or recurrence again and increments either:
1. the schedule line's Number of Retries for one-time scheduled payments and installment payments
2. the schedule's Number of Retries for recurring payments.

Staff can also manually pay a scheduled payment after it fails (or even before it is scheduled to be paid for).

Accounting Batches

As the Process Scheduled Payments scheduled job runs, if an automatic batch has not already been created for the current day, the job creates one with Source set to Scheduled Payments. As the job generates payments, all the resultant transactions are added to this batch.

To simplify reconciliation, you can also set a maximum number of transactions per batch. When you specify a Number of Transactions Per Batch in the Nimble AMS package configuration, the Process Scheduled Payments scheduled job will create as many automatic batches as necessary to contain all the transactions generated from processing carts that day.

Voids

Before a payment has settled in the payment gateway, staff can process voids for an order using the Staff View order process.

A void deletes the charge from a constituent's account in the payment gateway before the charge has been settled by the credit card processor. In the Staff View order process, a void can only be processed if the payment has not been settled. Credit card payments can take up to 24 hours to settle in the payment gateway. Each night Nimble AMS runs a scheduled job that reaches out to the gateway to determine which payments have been settled. Once the payment has been settled, it must be refunded rather than voided.

Voids to eCheck payments must be processed manually in the payment gateway.

Refunds

After payment has settled in the payment gateway, staff can process voids and refunds for credit card payments for an order using the Staff View order process. Full or partial refunds in Community Hub are automatically processed for constituents.

When using the Authorize.Net payment gateway, you can make full or partial refunds within 120 days of the initial payment. After 120 days, the token provided by the payment gateway expires and an automated refund is no longer possible. To refund after 120 days, staff must re-enter the credit card information and process the refund as a new payment with a negative amount. This limit is imposed by Authorize.Net and set on the payment gateway record. Learn more.

Refunds to eCheck payments must be processed manually in the payment gateway.

As of now, Partial refunds using the eCheck/ACH Stored Payment Method are not supported with the CardPointe Payment Gateway Integration.