Moltline Merchant Maths

Break down payment-processor fees: fee, net, and effective rate. FREE. Uses editable presets for stripe/paypal/square/shopify (verify current rates) or your own custom_pct + custom_fixed. Typical input {"amount": 1000, "processor": "stripe", "transactions": 10} returns {"gross": 1000, "fee": 32.0, "net": 968.0, "effective_rate_pct": 3.2, "note": "..."}. Use when the charge amount is known and the net payout is the question. Not for the reverse: the gross needed to net a target is charge_to_net. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": "<what is wrong and how to fix it>"} (for example {"error": "amount must be > 0, transactions >= 1"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.

Compute the gross price to charge so you net a target after fees. FREE. 'Charge X to receive Y' after percentage + fixed processor fees. Typical input {"net_target": 100, "pct_fee": 2.9, "fixed_fee": 0.30} returns {"charge": 103.4, "fee": 3.4, "net": 100.0}. The inverse of processor_fees - solves for gross from a target net. Use when the payout is the fixed requirement. Not when the price is already set. Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": "<what is wrong and how to fix it>"} (for example {"error": "net_target > 0 and pct_fee < 100 required"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.

Total an invoice: per-line totals, subtotal, discount, tax, grand total. FREE. Typical input {"line_items": [{"desc": "Design", "qty": 2, "unit_price": 50}], "tax_pct": 8.5, "discount_pct": 10} returns {"lines": [{"desc": "Design", "qty": 2, "unit_price": 50, "line_total": 100.0}], "subtotal": 100.0, "discount": 10.0, "tax": 7.65, "total": 97.65}. Use when several line items roll up with discount and tax. Not for one transaction's fees (processor_fees) and not for spreading a total over time (installment_plan). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": "<what is wrong and how to fix it>"} (for example {"error": "line_items must contain at least one item,"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.

Stack discounts correctly: sequential vs additive comparison. PREMIUM (license). The two methods differ — this shows both, the final price, and the true total discount. Typical input {"price": 200, "discounts_pct": [20, 10]} returns {"original": 200, "sequential_price": 144.0, "sequential_total_discount_pct": 28.0, "additive_price": 140.0, "difference": 4.0, "note": "..."}. Use when more than one discount applies and the order changes the answer. Not for a single discount inside an invoice (invoice_total). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": "<what is wrong and how to fix it>"} (for example {"error": "price > 0 and at least one discount required"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.

Compute a prorated charge or refund for a partial billing period. PREMIUM (license). Typical input {"amount_per_period": 90, "days_used": 10, "days_in_period": 30} returns {"days_used": 10, "days_in_period": 30, "prorated_charge": 30.0, "prorated_refund": 60.0, "answer": 30.0}. Use when a plan starts, ends, or changes mid-period. Not for splitting a full amount into scheduled payments (installment_plan). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": "<what is wrong and how to fix it>"} (for example {"error": "need amount > 0 and 0 <= days_used <= days_in_period"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.

Split a total into an installment schedule with optional deposit. PREMIUM (license). Rounding remainders land on the final payment so the schedule always sums exactly. Typical input {"total": 1000, "installments": 3, "deposit_pct": 10} returns {"deposit": 100.0, "payments": [300.0, 300.0, 300.0], "check_sum": 1000.0}. Use when one total is paid across scheduled dates. Not for partial-period adjustments (proration). Errors: on invalid, missing, or malformed input this tool never raises a protocol error — it returns {"error": "<what is wrong and how to fix it>"} (for example {"error": "total > 0 and 1-36 installments"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.