Payment Routing & Fee Calculator

A payment object with the type, amount, and channel does most of the work downstream, while the merchant profile and session context (device, location) travel along for enrichment.

Each payment.type maps to a processor, a base fee, and a starting risk score under a first hit policy: 'credit_card' routes to 'credit_processor' at 2.9 percent with a risk score of 25, 'debit_card' to 'debit_processor' at 1.5 and 15, 'bank_transfer' to 'ach_processor' at 1.0 and 10, 'cryptocurrency' to 'crypto_processor' at 1.8 and 35, and 'digital_wallet' to 'wallet_processor' at 2.5 and 20. Unrecognized types hit the default row at 3.5 percent and a risk score of 50.

The fee ladder tracks real acquiring economics: 2.9 percent is a common headline rate for card-not-present credit card processing, debit interchange runs materially cheaper, and ACH transfers are the cheapest rail of all. Cryptocurrency starts with the highest risk score of the named types because settlement is irreversible, and pricing the unknown default worst is a standard defensive posture.

Fees and risk are adjusted per payment.channel, with each of 'web', 'mobile', and 'pos' split on whether the base risk score exceeds 30: web adds 0.5 fee and 15 risk in the high-risk split versus 0.3 and 5 below it, mobile runs 0.8/20 against 0.5/10, and 'pos' adds at most 5 risk. The 'api' row applies a flat 0.1 fee addition with 'high' priority regardless of score, and the default channel is priced at 1.0 with 25 risk and 'low' priority.

Card-present POS traffic carrying the lowest risk additions mirrors the industry's card-present versus card-not-present distinction, since a physically presented card is far harder to abuse than a typed-in number. The near-free 'api' row reflects trusted server-to-server integrations where the merchant has already been vetted, and the priority field lets clean channels jump the processing queue.

Value tiers set both a fee adjustment and a security posture: payments of 10000 or more take a -0.5 fee discount but add 30 to security risk and demand '3ds_and_manual' verification, the 5000 to 10000 band gets -0.3 with '3ds', 1000 to 5000 keeps fees flat with a 'cvv_check', and under 1000 pays a 0.5 premium with 'standard' checks. Two route-specific rows at the bottom define ach_processor and crypto_processor handling at 5000 and above ('account_verification' and 'blockchain_verification'), though under the first hit policy the generic amount rows above them match first.

Discounting large transactions while hardening their verification is standard acquiring practice: percentage fees over-recover on big tickets, so processors rebate them, while absolute fraud exposure grows with size, which is why 3D Secure and manual review gate the top tier. The 1000/5000/10000 breakpoints themselves are business calibration, not a regulatory schedule.

All three components merge here: final_fee_percentage sums fee.base_percentage, fee.channel_addition, and fee.amount_adjustment, fee_amount applies that rate to payment.amount, and a floor expression keeps fee.final_amount at no less than 0.5. The node also derives payment.net_amount, the figure the merchant actually receives, so settlement logic downstream needs no arithmetic of its own.

Risk contributions from type, channel, and amount are added into security.total_risk_score, which then gates everything else: a high_risk_flag at 50 or more triggers manual review, velocity_check_required starts at 30, and fraud_scan_level steps through 'minimal', 'basic', 'standard', and 'enhanced' at the 25, 50, and 75 marks. The final processing_instructions object packages processor, priority, and every security decision into one directive for the payment gateway.