Currency rounding adjustments

To accommodate markets with limited small currency denominations and specific cultural payment norms, Clover offers a rounding feature.

When a merchant enables this feature (Settings or Setup > Payments > Rounding), Clover automatically adjusts the final transaction total based on regional requirements and merchant configurations. For example, rounding to the nearest 5 cents for cash transactions because smaller denominations are no longer available.

If you are building ecommerce integrations, custom point-of-sale (POS) apps, or using the Clover payments integration SDKs, you must account for these rounding adjustments in your application logic, user interfaces, and receipt generation.

Core concepts and order of operations

A rounding adjustment is always applied as the final, post-tax adjustment to a payment request. It does not alter item prices, taxes, service charges, or discounts.

Base currency units

To maintain unified logic across diverse global markets, Clover calculates round adjustments using the smallest indivisible unit of a currency (for example, a cent in USD or a yen in JPY). This provides a stable framework regardless of how different ISO 4217 currencies use decimal placements.

• 1s position: Always 1x the base unit (for example, $0.01 or ¥1)
• 10s position: Always 10x the base unit (for example, $0.10 or ¥10)
• 100s position: Always 100x the base unit (for example, $1.00 or ¥100)

Round logic example (nearest 0.05)

For regions like the United States, Canada, and Australia, the standard configuration adjusts the 1s position up or down based on its relative distance to the nearest 0 or 5.

📘

Note: A round-up adjustment can cause an increment in the 100s or 1000s position, for example, a total of $19.99 with a +$0.01 adjustment becomes $20.00.

API and data model impacts

If your application interacts with the Clover Order, Payment, or Refund objects, you must update your integration to parse and handle round events.

🚧

Important: Do not hardcode round logic into your app. The round direction (up, down, nearest), unit (1s, 10s), and applicable tender types (cash only versus all tenders) can vary by region and merchant configuration. Rely strictly on the adjustment values returned by the Clover API.

1. Payment and Order objects

The round adjustment is clearly documented in the Clover database and payment records as a discrete line item.

• The adjustment value can be positive (when you round up) or negative (when you round down).
• If you calculate order totals programmatically, you must parse the round adjustment field and apply it to your final amount collected.

2. Process refunds

For regions where a round adjustment is required due to currency limitations, refunds must respect the round logic used at the time of the original payment. This includes partial refunds.

• Example 1: If the total is $10.67 (inclusive of tax) on an order originally paid in cash and rounded down to $10.65 (a -$0.02 adjustment), a full refund in cash will account for the original rounding method. A $10.67 (inclusive of tax) refund in cash will be rounded down to $10.65 (a -$0.02 adjustment).
• Example 2: If an order total for two items is $10.67 (inclusive of tax) on an order originally paid in cash and rounded down to $10.65 (a -$0.02 adjustment), a partial refund for an item totaling $4.68 will be adjusted by +$0.02 to yield a total refund of $4.70. The same set of rounding rules applies to the original transaction and the partial refund, though the rounding amounts may differ.
• Maximum refund limit: A merchant cannot refund more than what was initially collected.

3. Payments integration (Remote Pay API and SDKs)

If you use the Clover Payment Connector API, Remote Pay SDK, or USB Pay Display SDK, your third-party POS system will receive notifications of round events.

• You must make sure your third-party application captures this rounding data by parsing the rounding adjustment parameter returned in the Payment object or SDK response payload, then displaying the adjusted total on your POS interface. For more details on parsing response payloads, see the Remote Pay SDKs and Payment Connector API documentation.
• Third-party displays tethered to a Clover device must clearly reflect the round adjustment to the customer during the transaction.

4. Receipts and reporting

Round adjustments are classified as a separate, non-revenue and non-tax category.

• Receipts: Custom receipt implementations (both paper and web) must display the round adjustment as a distinct line item just above the final amount collected.
• Reporting: If your app pulls reporting data through CSV exports or APIs, parse the new round adjustments parameter to ensure your third-party ledger balances accurately.