Charges
Charges are transactions paid to an Organization by a constituent’s credit card or bank account (ACH). Charges must be initiated from within your Application; they cannot be created from the Merchant Portal. Charges can be captured and follow this flow:
They can also be authorized first and captured (or voided) later, using this flow:
Creating Charges
Charges are created with the NeonPay API. Here's a simple example of how a charge can be created with a single call:
POST /api/charges
HEADERS:
Content-Type: application/json
Accept: application/json
X-API-Key: key_abcdef123456
X-App-ID: 12
BODY:
{
"merchant_id": 32,
"amount": 5000,
"type": "cc",
"currency": "usd",
"funding_currency": "usd",
"origin": "ecommerce",
"token": "token_0934029jdsfgjd",
}Notice that card or banking information is not sent directly through the API. Instead, payment method tokens are used. Please refer to the the Tokenization section below for more information.
Assigning Charges to Merchants
All transactional records in NeonPay (charges, refunds, disputes, and payouts) are associated with a Merchant Account owned by one of your customers (Organizations). When creating charges or other records, you must include a merchant_id parameter in your request body.
NeonPay will only allow you to use the merchant_id of an account already associated with your application. Your application's API credentials are not specific to each merchant (as is the case with some payment processors). Instead, you use a single set of API credentials for your application and supply a merchant_id with each API request you make.
Recurring Charges
NeonPay does not provide any logic to facilitate scheduled payments; your Application must manage payment schedules. Payment tokens can be created and then saved in your Application and used later. Simply create a new charge using an existing token, and (using the recurring field on the Charge object) specify the payment as having been part of a recurring schedule.
Tokenization
NeonPay employs client-side tokenization for securing sensitive data (such as credit cards or bank accounts) in the processing of payments. When collecting payment data on forms, implement NeonPay.js as a means to tokenize this data prior to sending it to NeonPay's API.
The primary benefit to your application is the reduction of PCI compliance risk. Since sensitive data never touches your application directly, you have a much smaller risk profile.
This illustration shows the process of tokenizing credit card or bank account data:
Fees
Fees are charged to organizations in a number of scenarios. All of these fees are configurable in the Merchant Portal by Application or System Administrators on a Merchant-by-Merchant basis. We set default fee amounts for each Application that are applied to an Application’s new Merchants, but the fees can then be overridden for any merchant manually.
Fees are are collected from merchant accounts by applications. Fees are collected from applications by NeonPay.
Standard Processing Fees
These are the standard fees associated with all merchant accounts. Your application charges these fees to merchants. You may set defaults for these rates from the NeonPay Portal, but you may also override the rates on a merchant-by-merchant basis. The rates you set as default or specifically to a merchant will be the rates charged to a customer. NeonPay will collect transaction fees at agreed-upon rates from your application.
| Fee | Description |
|---|---|
| Authorization | Flat fee assessed when a charge is authorized. |
| Capture | Flat fee assessed when a charge is captured. |
| AMEX Surcharge | Additional percentage fee assessed when an American Express charge is captured. |
| ACH Transfer Flat Fee | Flat fee assessed when an ACH charge is processed. |
| ACH Transfer Percent Fee | Percentage fee assessed when an ACH charge is processed. |
| ACH Transfer Failed Fee | Flat fee assessed when an ACH charge fails. |
| ACH Return Fee | Flat fee assessed when an ACH charge is reversed by a bank. |
| Chargeback Fee | Flat fee assessed when a chargeback is created. |
| Retrieval Fee | Flat fee assessed when a retrieval (similar to chargeback) is created. |
Platform Fees
Platform fees may not be used by all applications. You may use these to add an arbitrary additional fee, either in percentage or flat rate, to charges.
| Fee | Description |
|---|---|
| Platform Flat Fee | Flat fee assessed when a charge is captured. This is an arbitrary fee in addition to the Auth and Capture fees. |
| Platform Percent Fee | Percentage fee assessed when a charge is captured. This is an arbitrary fee in addition to the Auth and Capture fees. |
Refunds
Existing charges can be refunded. Refunds can be initiated either through the API or from the Merchant Portal. Using the Refunds API, simply specify the ID of the charge to be refunded and specify the amount to refund. NeonPay supports partial refunds, and a single charge can be refunded multiple times (until the original amount has been fully refunded).
NeonPay provides API methods and webhooks related to Refunds. We recommend that you support refunding from within your Application, but also listen for notifications of refunds initiated from the Merchant Portal to ensure updates are reflected in your Application.
Refunding Fees
At this moment, it is not possible to refund transaction fees to a customer. This capability is under development and will be added in the future. This document will be updated with the recommended process for doing so.