Commercial Charge

Commercial Charge Card Products allow you to issue lines of credit to your customers. The COMMERCIAL_CREDIT_PAY_IN_FULL product does not charge interest and requires your customers to pay their statement balance in full by the due date each billing cycle.

Credit Card Products not backed by an Account Holder’s secured deposit will require you or a debt facility to provide sufficient capital based on the lines of credit extended to your customers.

In the Test Environment, you can create a Commercial Charge Card Product from the Highnote Dashboard or with the createCardProduct mutation in the Highnote GraphQL API. When creating your Credit Card Product, you’ll want to select COMMERCIAL_CREDIT_PAY_IN_FULL as the vertical.

For Commercial Charge Products, you can simulate a deposit into your Product Funding Account in the Test Environment. These funds will be used to allocate credit lines to your Account Holder's Financial Accounts. Simulating deposits does not require you to connect an external bank account. To deposit funds, you’ll first need to find your Product Funding Financial Account ID.

With your Product Funding’s Financial Account ID, you can now simulate a deposit via WIRE. Afterward, you will be able to set the credit limit for the Account Holder’s Financial Account, once issued.

The memo field can be used to display what typically appears on a given transfer. In the Live Environment, you won’t have the ability to control the memo field as there are specific guidelines on how WIRE and ACH appear to an Account Holder.

The SimulateDeposit API will set the Available Credit for your Commercial Credit Product Funding Account.

You can create a Business Account Holder from both the Highnote Dashboard and GraphQL API. When creating an Account Holder, there are optional, creditRiskAttribute fields which you may want to provide as inputs to a credit application. annualRevenue is one optional field which can be collected on an Account Holder to be used in your application credit decisioning and simulate application credit decisions in the Test Environment.

Once you have created a Business Account Holder, you can open an Application to onboard them to your Card Product.

Opening an Application triggers the identity verification checks and any applicable credit policies necessary for your Card Product. Your Card Product will define the required Application fields for identity verification and credit risk underwriting. These checks must pass in order to onboard the Account Holder. To create the Application you will need the cardProductId and accountHolderId.

To simulate credit line assignments or Adverse Actions reasons on your Credit Card Product in the Test Environment, you need to include specific annualRevenue on the Account Holder before creating a Card Application. See the “Simulate Credit Line Assignment” and “Simulate Adverse Action Declines” for more information.

The Test Environment does not run KYB (Know Your Business) and KYC (Know Your Customer) checks on Applications. When testing, you can simulate Application failures under a variety of scenarios by creating Account Holders with specific attribute values. The simulation will produce Tags associated with the application decision and provide information as to why an Application outcome was APPROVED, IN_REVIEW, or DENIED.

Note: When simulating credit line assignment, be sure to not use any of the failure values outlined in the Simulate Verification Status guide which would decline the Application. An Application must be simulated for approval for a credit line assignment to be provided in the response. If the annualRevenue is not one of the input values below, an approved Application will have a $1,000 credit limit.

For Credit Card Products, your credit policy may allow you to dynamically assign a credit limit for an approved Application. Opening an Application on a Credit Card Product in the Test environment allows you to test various credit line assignments on an APPROVED Application response by providing specified values on the annualRevenue input when creating a Business Account Holder. The annualRevenue value will be used when you create an Application for the Card Product for the Business Account Holder.

For Credit Card Products, regulation requires you to provide Adverse Action (AA) reason(s) to the Account Holder within a specified timeframe when an extension of credit is DENIED. Adverse Action reasons are assigned and associated with each rule within your Product's credit policy and are populated based on the rules which failed in the credit decision. For example, if your credit policy has a rule that the Annual Business Revenue provided in the application must be greater than a specified amount, the application may be DENIED with the AA reason of "Income insufficient for the amount of credit requested."

Opening an Application on a Credit Card Product in the Test environment allows you to test various Adverse Action reasons on a DENIED response by providing specified values on the legalBusinessName and/or annualRevenue inputs when creating the Business Account Holder. The annualRevenue and legalBusinessNamevalues will be used when you create an Application for the Card Product for the Business Account Holder.

In the Live environment, a DENIED Application may have 1 or many associated AA reasons which must be provided to the customer.

Financial Accounts hold the balance for Payment Cards. To create a new Financial Account pass the ID of a verified Application.

Financial Accounts have an externalId that allows you to tie the Financial Account to an entity in your system. If you do not pass in an externalId, Highnote will generate one.

For Product verticals such as Credit or Fleet, you may create a credit limit on your account holder's financial account based on your underwriting criteria, agreements and product guidelines. The credit limit establishes a maximum spending limit for a given time period and authorizations that exceed the credit limit will be declined.

Once you have created a credit limit, you have the flexibility to update a credit limit as you factor in new information, such as changes in your customers' financial situations.

As part of this feature, Highnote tracks the total credit extended to your Account Holders' Financial Accounts and ensures the extended credit does not exceed your Product Funding balance.

Note: Setting or updating a credit limit is an asynchronous process to ensure your ledger balances and validations are in check.

Once you have created and funded a Financial Account, you can issue a Payment Card. All Payment Cards start as a virtual card, and can later be ordered as a physical card.

You may only submit one order for a given Payment Card. If the order is canceled or fails, you may try again for the same card. However, if an order is successful and you need another Physical Card, you will need to issue a new Payment Card.

Once you have issued a Payment Card you can create an order for a Physical Card. When ordering a Physical Card, you can ship to the Account Holder's address on file or specify a different shipping address.

Physical Card orders require:

• Card Personalization Details
• Shipping Address
• Requested Ship Date
• Shipping Method and Signature Requirements

Use the following mutation to create a Physical Card order:

Selecting the number or cvv fields requires that you are PCI compliant.

Highnote recommends using the Card Viewer SDK to securely display payment card data and and reduce PCI burden.

To display the primary account number (PAN) and CVV to users, you can fetch them from the API by adding number and cvv to the selection set

Recurring payments (or automatic payments) and one-time payments are used for Card Products which require a payment to be made by the Account Holder on a regular cadence. You’ll need to provide your Account Holders with the ability to make payments towards their outstanding or statement balance.

To schedule a repayment, an Account Holder must connect a verified, external bank account. Highnote has partnered with Plaid and Finicity as secure options for your Account Holders to verify and link their external accounts. Once linked, Account Holders can seamlessly transfer funds (via ACH) between the Highnote Financial Account and the external bank account. Prior to creating a payment schedule, you learn how to test connecting an external account via Plaid or Finicity from the Connect External Accounts Guide.

A Recurring Payment schedule can be set on a monthly frequency so that your customer’s can schedule payments on their due date each month or on a customized calendar day. Recurring payment schedules are based on a point-in-time balance, such as Outstanding Balance, and the ACH transfer amount will be calculated on the scheduled date.

A Recurring Payment schedule can be set on a monthly frequency so that your customer’s can schedule payments on their due date each month or on a customized calendar day. Recurring payment schedules are based on a point-in-time balance, such as Outstanding Balance, and the ACH transfer amount will be calculated on the scheduled date.

Highnote provides the data necessary to create a statement for a Financial Account, which you can leverage to populate your own statement template and provide to your customers.

Billing statement data is created on Financial Accounts and becomes available at the end of a billing cycle. For Credit Card products, the billing period end date may vary across Financial Accounts on your portfolio. Statement data is typically available within 48 hours of a billing period end date.

You can query the latest billing statement data for a Financial Account to generate the Account’s statement in the latestClosedStatement. Billing statements will only include posted transactions and the associated balances for a given billing period. Transactions for the Financial Account’s current billing period and their next, upcoming due date can be found in the currentOpenStatement.

When there is a balance due on the Financial Account, the currentAmountDue will be updated based on credits (e.g. payments, refunds) to the Financial Account between the billing period end date and the due date. You’ll need to reference the type of CreditPayInFullCardFinancialAccountStatementSnapshot to retrieve the current amount due, based on your Card Product. You can present this balance to your customer outside of the statement itself so they are informed on the remaining amount owed since their last statement was generated.

In the Test Environment, you can end a Financial Account’s billing period early so you can simulate a billing period’s statement without waiting for the billing period to end.

The new period must be at least 60 seconds in the future, and if the periodBoundary is not supplied, the statement endPeriod will be set to 60 seconds in the future.

In the Test Environment, you can roll over a Financial Account’s billing period to the next billing cycle so you can simulate ending and starting a new billing cycle for a Financial Account. Rolling over to the next billing period allows you test and view how the statement data for a closed billing period is calculated without waiting until the actual calendar day for the billing period to close.

For more information on generating or searching for billing statements, see our Billing Statements Guide.

Once you've completed the basics of setting up your card product, you can expand and test your integration further:

• Simulate Transactions in the Test Environment to ensure your integration works
• Create Spend Rules to control the way your cards can be used
• Setup Notifications to automate your integration