Fees

Lotus is able to handle two types of fees.

Type of Fees

• Core: Standard fees set by Girasol “Lotus Admin” that will be automatically imposed by
• Custom: Fees configurable per issuer or co-applicant

Automated Fees

Collaborate with Girasol to automatically apply fees to your products. When fees are automatically assessed, the following conditions will apply:

• Fees are automatically applied to all eligible “events”. Common examples include replacement card fees, expedited shipping fees, international ATM withdrawals, etc.
• Revenue from fees is deposited into a designated account at your partner bank. Coordinate with your issuing bank to determine the destination of the revenue. Consult your completed Funds Flow document provided by Girasol to understand where the revenue from these fees will be directed.
• Most fees are applied immediately. If the cardholder balance is zero or if the account balance is less than the fee amount, fees can be set to pending and will be processed automatically once the account balance is sufficient to cover the fee.
• Fees cannot be programmatically waived for unique situations. Instead, Issuer can manually reverse the fee using the “Reverse Fee endpoint”.
• Girasol can programmatically waive the first XX eligible fee events on an account or waive XX instances of a specific fee within a given period. For example, waive a specified fee every 365 days or waive two fee events each month. Only one fee waiver configuration can exist for a given fee type per product. Girasol works with you to programmatically set up these rules.
• Fee waivers can be established on a rolling basis (30 days, 365 days) or on a monthly basis (reset on the first day of each month).
• Girasol can assess periodic fees. Periodic fee options include: o Dormancy Fees o Weekly Fees, Monthly Fees, Annual Fees
• Refer to Girasol's system fee values for a complete list.

Custom Fee

Issuer has the option to assess and setup own fees using the [Assess Fee endpoint] The Assess Fee endpoint ingests a unique fee code, which is specific to your program. Work with Girasol to set up three-digit fee codes for your program, along with their corresponding fee ftypes, descriptions, and expiration values.

Adhere to compliance requirements ensure you adhere to any of the following requirements:

• Most countries maintain strict regulations surrounding fee-naming conventions.
• Most cardholder agreements must include a list of fees and the accompanying events that will incur a fee.
• The fee names should match in every aspect of cardholder-facing documentation and within your application and website.

Establish money movement rules

Girasol can perform money movement for fees. If Issuer plan to use custom fees, each must coordinate with Girasol and the Issuing bank (if applicable) to determine who should be performing money movement, and make sure that fees are included in the funds flow. Once money movement for fees has been set up, Issuer can configure additional fees without needing to revisit your funds flow diagram.

Fee transaction codes

The fee transaction type, also called ftypes, for standard fees consists of four digits paired with the “FE” activity type (act_type). For example, a domestic ATM fee is FE0013 and an international ATM fee is FE0014. Issuer should be able to see these transaction codes in event messages, the Posted Transactions RDF, and transaction-retrieval Program API endpoints.

Fee rules

Fees notes

• Percent-based fees will assess a percentage of the total amount of the transaction. If an ATM operator charges a 2.95 fee to use their ATM for a 20.00 withdrawal, and a 3% fee is assessed, the fee amount will be 3% of 22.95.
• Some fees are assessed during authorization. For example, Aaron withdraws 20.00 from an out-of-network ATM and you charge an ATM withdrawal fee (ATD) of 2.95. The ATM operator charges a 3.50 convenience fee. The authorization amount for this transaction is therefore 26.45. If cardholder has an available balance of 25.43 on his account, this authorization is declined. If cardholder has an available balance equal to or greater than 26.45, the transaction would be authorized.
• The authorization for this transaction will show 26.45 in the Authorized Transactions RDF, the CST, and Program API responses. Settlement will show two transactions, one representing 23.50, and the other showing the 2.95 fee.
• At settlement, the record for this transaction will be split into two separate amounts. One will show the 23.50 withdrawal, and the other will show the 2.95 fee.
• Fees triggered by authorizations are linked in both the RDFs and Events API. Use the ORIGINAL AUTH CODE in the Posted Transactions RDF to connect a fee to the transaction that triggered the fee. The BFEE: fee event message can be configured to include the fee_auth field, which links a fee event back to the original authorization.
• Fees assessed using the Assess Fee endpoint do not have a connection to their triggering events.

Fee Reporting

The Posted Transactions RDF contains fee details in the following fields:

• NEGATIVE BALANCE FEE AMOUNT: Identifies the amount of a fee(s) assessed to an account when the account was driven negative.

• AUTHORIZATION CODE: An internal-generated identifier for the transaction. Pair this value with the first two characters of TRANSACTION CODE/TYPE to create an identifier that is unique across all transactions.

Other reports

• Rollforward report: Contains a summary of various types of financial activities, including fees.
• Settlement-BIN Summary report: Shows all settlement activity related to card-network transactions, including fees.
• Fee Overview report: Shows the total amounts for various types of fees for the selected date range. Data is available at daily, weekly, and monthly levels.
• Fee Monthly Summary report: Shows the fee trend, average fee per cardholder, and how many active accounts were not charged a fee.
• Fee Reversal Summary report: Shows a summary of all fee reversals for the selected date range. Data is available at daily, weekly, and monthly levels.
• Revenue report: Shows the total revenue generated by your products during the past 12 months. Includes an option to view revenue by fee type, among other categories.

Pending Fee

In the case where an account has sufficient balance to cover a fee, the fee will be processed. However, if an account balance is 0.00 or less than the amount of the fee, you have the option to set a fee to a pending status (pend). You determine if a fee can be set to pending or not. If a fee is not configured to pending, a fee will not be assessed for the given scenario. In some cases, this will cause the original process to fail. For example, if a REP (replacement card) fee cannot be assessed for a lost or stolen card because of insufficient funds, the card-replacement process stops. If there are multiple pending fees, fees are assessed in the order they were created once funds become available. To cancel a fee in pending status, use the “Reverse fee” endpoint. To see a list of pending fees for a customer's account, call “get pending fees” endpoint.

Fees expiration

Fees can be configured to expire after a number of days. If a fee does not drive an account balance negative, and the fee is set to pending, then the fee remains in a pending state until the fee expires. Fees expire after a set number of calendar days, defined for each fee. Most commonly, a fee expires after 90 days.

• Use the “get pending fees” endpoint to retrieve the fees that have not yet been processed against the specified customer account.

Reversing a fee

If a fee was assessed, based on your product setup:

1. Retrieve the fee Id using the “get Fee History” endpoint.

2. Use the “reverse fee” endpoint to reverse the fee.

3. Pass the fee Id of the endpoint request to be reversed, instead of passing a new value.

If you assessed a fee using the Assess Fee endpoint:

1. Use the “reverse fee” endpoint to reverse the fee.

2. Pass the transactionId of the endpoint request to be reversed, instead of passing a new value.

Alternatively, you can use the CST to post an adjustment to the account. Fee reversal types vary based on the fee type that is being reversed. If a fee is programmatically accessed, such as an ATM fee, and the ATM operator reverses the transaction, Galileo does not reverse the associated fee. You must reverse it yourself using the “reverse fee” endpoint, or you can decide not to reverse the fee, according to your business plan.

Issuer Portal, issuer can view the fees that have been configured for each product. Select the product page, and then open the Fees dialog. You can see the name of the fee, the 3-character code, the ftype, the fee amount (flat or percentage), the expiry days, and what to do if the account has insufficient funds.