1. Scope
This Policy governs Hammer payment-related functions and Supplier settlement where incorporated into the transaction framework. It should be read with the Marketplace Terms and the Buyer, Supplier, Refund and Delivery policies.
2. Roles
A Requester selects or manages Goods; a Payer is nominated or authorised to pay; the Buyer acquires the Goods. The roles may be held by the same or different persons.
3. Payment methods
Hammer may offer only payment methods actually enabled through approved production providers. Availability may vary by transaction, amount, user, provider, risk controls or operational status.
4. Provider promises
Hammer should not publish provider-specific limits, settlement times or capabilities until the production integration and commercial agreement are final.
5. Payment Request
A Requester may send a secure Payment Request containing enough context for informed review, including relevant lines, quantities, prices, Suppliers, project/site context, Delivery charges and total payable.
6. Payer nomination
Requester must use accurate Payer contact details and a legitimate reason for nomination. The feature must not be used for spam, harassment or unauthorised disclosure.
7. Payer review
Where enabled, a Payer may approve/reject individual lines and propose permitted quantity/cart changes.
8. Requester reconfirmation
A Payer-proposed change marked as requiring Requester confirmation does not become final until reconfirmed. Hammer should preserve the proposal and confirmation history.
9. Payer authority
A Payer proceeding represents that they are authorised to use the chosen payment method and make the relevant payment.
10. Payer status
Payment alone does not automatically make the Payer the Buyer, owner, consignee or recipient unless the Order expressly says so.
11. Secure links
Payment Request links should be protected and expire or re-authenticate where appropriate, exposing only information necessary for the payment decision.
12. Contract formation
A Payment Request alone is not necessarily a binding sale. Contract formation follows the Marketplace Terms and final Order workflow.
B. PAYMENT CONFIRMATION AND EXCEPTIONS
13. Pre-payment review
Payer should be able to review the material amount and Order information before payment. Material changes after review should trigger the required reconfirmation.
14. Initiation is not confirmation
An initiated transaction, bank prompt, screenshot, mobile-money message or pending provider status is not final confirmation to Hammer.
15. Verified payment
Hammer may rely on authenticated bank/provider status, settlement data, reconciliation or another reliable confirmation mechanism appropriate to the method.
16. Supplier release gate
Where Hammer requires payment confirmation before fulfilment, Supplier remains blocked until Hammer records the required state.
17. Duplicate payments
Apparent duplicates should be investigated and not treated as additional entitlement without verification.
18. Overpayments
Verified overpayments should be reconciled and returned or otherwise handled lawfully, not silently converted into unrelated credit.
19. Underpayments
An underpaid Order should not be treated as fully paid unless an authorised adjustment, credit or revised Order makes payment sufficient.
20. Partial payments
If deposits/instalments are introduced later, the Order must state paid/outstanding amounts and fulfilment consequences. Until implemented, Hammer should not imply partial payment support.
21. Expiry
A Payment Request or quoted amount may expire where price, stock, Delivery or risk conditions can change; expiry must not erase the audit record.
22. Provider outages
Provider/network failures may delay confirmation. Hammer should not release Goods solely because a user asserts payment succeeded.
23. Payment reference
Each payment should be reliably linked to the relevant Order/Payment Request and retained in the audit history.
24. Reconciliation
Provider/bank records should be reconciled against Orders, refunds, reversals, fees and settlement records before Supplier money is released.
C. FRAUD AND PAYMENT SECURITY
25. Fraud controls
Hammer may use identity checks, device/session signals, velocity limits, manual review, holds and other proportionate controls.
26. Suspicious payments
Hammer may decline, hold or seek additional verification for suspicious, inconsistent, high-risk or legally restricted transactions, subject to law.
27. No fraud guarantee
Controls reduce risk but do not guarantee every fraudulent or unauthorised transaction will be detected.
28. Credentials
Full card credentials, banking passwords and OTPs should remain with appropriately authorised providers wherever practicable. Hammer staff should never request passwords or OTPs.
29. Provider terms
Banks/gateways may independently apply authentication, limits, holds, reversals and dispute procedures.
30. Payment incident
Suspected account takeover, unauthorised refund, settlement-detail fraud or payment manipulation should trigger escalation and evidence preservation.
D. TAX, INVOICES, FEES AND DELIVERY
31. Customer acknowledgement
Hammer may provide an Order/payment acknowledgement without misrepresenting it as the Supplier's tax invoice where Hammer is not the legal supplier.
32. Taxable supplies
The accounting design must distinguish the Supplier's sale of Goods, Hammer's service/marketplace fee, Delivery service and other taxable supplies. The person legally making each supply should issue the required invoice.
33. eTIMS
Hammer's systems and contracts must reflect applicable KRA electronic tax-invoicing obligations and actual legal roles rather than issuing one generic invoice for distinct supplies.
34. Buyer Initiated Invoicing
Do not represent that Hammer issues Supplier tax invoices through Buyer Initiated Invoicing unless the applicable KRA requirements, approvals, consent, system and audit controls are satisfied.
35. Reverse invoicing
Any reverse-invoicing mechanism must be legally applicable and operationally implemented; it is not a generic marketplace shortcut.
36. VAT display
Where VAT or other tax is included or added, price presentation and the Order record should make the treatment clear as required.
37. Marketplace fees
Supplier commissions/fees should be governed by the Supplier Agreement or agreed schedule. Buyer-facing charges should be disclosed before confirmation.
38. No hidden fees
Hammer should not add an undisclosed mandatory marketplace/payment fee after the legally relevant confirmation step.
39. Delivery charges
Delivery charges should remain allocated by Delivery Leg. Multiple origins may create multiple Delivery charges.
40. Discounts
Discounts, credits and promotions should have clear eligibility and the applied amount should be preserved in the Order snapshot.
E. REFUNDS, REVERSALS AND CHARGEBACKS
41. Refund authority
Refunds follow the Refund Policy and authorised internal controls. Supplier, driver or ordinary support users should not independently promise/issue Hammer-controlled refunds without authority.
42. Refund route
Approved refunds should ordinarily return through the original lawful payment route where practicable, subject to provider capabilities, fraud controls and law.
43. Refund states
Hammer should distinguish refund approved, submitted to provider and completed/confirmed where provider data supports those states.
44. Refund timing
Hammer should communicate status but not guarantee exact bank/provider posting time it cannot control.
45. Credits
If account credits are introduced later, expiry, transferability, refundability and tax treatment must be defined. Until then, do not imply stored-value functionality.
46. Reversal
A provider/bank reversal may make an Order unpaid/disputed after an earlier success state. Hammer may suspend Supplier settlement and investigate.
47. Chargebacks
Payer retains lawful dispute rights. Knowingly false or abusive chargebacks for authorised, conforming and properly delivered transactions are prohibited.
48. Chargeback evidence
Hammer may provide relevant Order, acceptance, payment, Supplier, pickup, Delivery, communication and dispute evidence to the bank/provider.
49. Recovery
Where payment is reversed despite a valid debt remaining due, Hammer and/or Supplier retain lawful recovery rights.
F. SUPPLIER PAYABLE AND MANUAL SETTLEMENT
50. Supplier amount payable
After customer payment is confirmed, Hammer may calculate the Supplier amount payable subject to the Supplier Agreement and reconciliation.
51. Settlement calculation
Supplier payable may account for Goods amount, agreed Hammer fees, allocated charges, authorised credits, refunds, disputes, chargebacks, taxes and other agreed adjustments.
52. No automatic payout at launch
Customer payment does not automatically trigger Supplier payout. Hammer records the amount payable and an authorised Administrator manually releases settlement after reconciliation.
53. Settlement cycle
Supplier Agreement should specify the normal reconciliation/settlement cycle. Hammer should not publish a payout timetable it cannot consistently meet.
54. Authorisation record
System should record settlement authoriser, amount, date/time, destination account and material adjustments.
55. Holds
Hammer may place a reasonable temporary hold to investigate fraud, duplicate payment, chargeback, refund, material fulfilment dispute, settlement-detail change, legal restraint or other material risk. A hold is not forfeiture.
56. Reserves
If rolling reserves or other Supplier-risk reserves are introduced later, they must be expressly agreed and not silently created through this Policy.
57. Settlement destination
Settlement should go only to verified authorised Supplier details. Changes should trigger enhanced verification.
58. Settlement errors
Erroneous overpayments remain recoverable to the extent permitted by law/contract; underpayments should be corrected through reconciliation.
59. Supplier disputes
Supplier settlement disputes should identify relevant Orders/calculations. Corrections should preserve the original reconciliation rather than overwrite it.
60. Multi-Supplier allocation
Customer payment for one Order may be allocated across several Suppliers and Delivery Legs. Line-/leg-level allocation must be sufficient to reconstruct the calculation.
61. Partial refund impact
A refund affecting one Supplier/line should not automatically alter unrelated Supplier entitlements unless the wider transaction requires it.
62. Delivery-provider settlement
Amounts payable to a Delivery provider should remain separately identifiable from Supplier Goods settlement.
G. REGULATORY CHARACTERISATION AND FUNDS
63. Payments-regulation analysis
Before first paid Orders, Kenyan payments counsel should confirm whether Hammer's collect-and-later-settle flow creates any payment-services, merchant-acquiring, trust, safeguarding, escrow, stored-value or other regulated characterisation requiring a licensed partner, structural change or additional controls.
64. No unsupported escrow claim
Hammer should not call customer funds 'escrow', 'trust funds' or legally protected in a particular way unless the actual banking/legal arrangement supports that claim.
65. AML and sanctions
Hammer and regulated financial partners may apply lawful identity, transaction-monitoring, sanctions or anti-money-laundering controls where applicable. Hammer must not claim regulatory status it does not possess.
66. Suspicious activity
Where legally required or reasonably necessary, a transaction may be held, rejected or reported to an appropriate provider/authority. Hammer should avoid prohibited tipping-off.
67. Currency
Order should state transaction currency. Foreign-currency support, conversion rates and FX fees should not be implied until implemented.
68. Insolvency
Counsel should determine treatment of customer funds, Supplier payables and unsettled transactions if Hammer, Supplier or payment partner becomes insolvent. Public wording must not promise protection the legal structure does not provide.
69. Set-off
Any right to set off established amounts owed by a Supplier against settlement should be expressly defined in the Supplier Agreement and subject to law.
70. Hammer taxes
Hammer is responsible for tax obligations on its own taxable services/fees. Accounting should distinguish Hammer revenue from amounts collected for Supplier Goods.
H. FINANCIAL CONTROLS, RECORDS AND CHANGES
71. Rounding
Tax, unit-price and allocation calculations should use consistent rounding rules to avoid unexplained discrepancies.
72. Access control
Payment, refund and settlement functions should be role-restricted. High-risk actions should use stronger authentication or dual control where appropriate.
73. Separation of duties
As values grow, the person preparing Supplier reconciliation should not be the sole person capable of approving/releasing it.
74. Audit logs
Material financial actions should record actor, timestamp, Order, amount, before/after state, reason and provider reference.
75. No silent edits
Historical payment/settlement records should not be silently overwritten. Corrections should create auditable adjustments.
76. Data protection
Payment data should follow the Privacy Policy and need-to-know access. Sensitive credentials must not appear in ordinary support logs/admin screens.
77. Business continuity
Maintain a controlled reconciliation fallback during provider outages without bypassing payment verification or approval controls.
78. Retention
Payment, tax, reconciliation and settlement records should follow statutory/claims requirements and Hammer's retention schedule.
79. Complaints
Payment complaints should use a traceable support process and be distinguished from product, Delivery and bank/provider disputes.
80. Provider escalation
Where resolution depends on a provider, Hammer should provide available evidence/status but not claim control over the provider's independent decision.
81. Policy changes
Material changes should be dated and communicated. New Supplier fees, reserves or materially different settlement mechanics should use the Supplier Agreement's required variation process.
82. Contact
The final page should provide the actual payment/support route and verified Golden Hammer business contact details.