- Each crypto processor now scans only its assigned Monero account
- Scan position is tracked independently per processor
- Fixed indentation in scan loop that was broken during refactoring
- Updated tests to match new per-account scanning behavior
- Resolves issue where payments on accounts other than 0 weren't updating scan position
- Add 'all_accounts': True to XMR get_transfers query
- Fixes scan position not updating when payments arrive on other accounts
- Dogecoin scan already works correctly (queries all addresses)
- Ensures new transfers on any account update the scan position
- Use only 'name' field from User model for privacy
- Remove references to full_name and email from logs
- Fallback to user ID if name is not available
- User model has 'name' not 'username' or 'display_name'
- Add joinedload for user and shop in all CryptoPayment queries
- Import sqlalchemy for ORM operations
- Ensures user display_name/username shows in payment logs
- Fixes missing user information in crypto_watcher logs
- Create make_post_sell/lib/crypto_watcher/ directory structure
- Move crypto_watcher.py to crypto_watcher/__init__.py
- Move crypto_payment_rescue.py to crypto_watcher/
- Move crypto_clients.py to crypto_watcher/
- Update all imports to use the new package structure
- Fix relative imports within the crypto_watcher package
- Update imports in request_methods.py, views, and all tests
- Fix late payment misidentification (pending vs confirmed status)
- Update terminology: 'late payment' only for expired/cancelled states
- All 141 tests passing
- Only log 'Overpayment within 5% threshold' when received > expected
- Skip the log message for exact payment matches
- Prevents confusion when payment amount exactly matches expected amount
- Replace all 171 direct logger calls with CryptoWatcherLogger methods
- Fix XMR scan position persistence issue (was resetting to None/0)
- Remove redundant formatting methods from CryptoPayment model
- Update all test mocks to use central logging system
- Ensure scan position updates even when no transfers found
- Remove pointless _get_status_description() that just returned self.status
- Remove useless format_transaction_log() only used in tests
- Consolidate duplicated amount formatting logic into _format_amount() helper
- Fix XMR precision from 6 to 12 decimals for accuracy
- Strip trailing zeros from formatted amounts for cleaner output
- Simplify format_confirmation_status() by removing redundant text
- Eliminate unnecessary method delegation in __str__()
- Apply black formatting
- Add section explaining real-time status updates on quote page
- Document automatic redirects to invoice/download upon confirmation
- Clarify that payment buttons are disabled once payment received
- Note that confirmations can be as fast as 2 for digital goods
- Remove duplicate dogecoin.conf examples from Advanced Configuration
- Simplify to reference make dogecoin-config command
- Keep only essential full node vs pruned mode trade-offs
- Remove incorrect SQL index examples from DOGECOIN.md and MONERO.rst
- Simplify Dogecoin node security section to reference make command
- Stop leaking database schema details in user-facing documentation
- Change from 50GB to 200GB+ for full blockchain size
- Update space savings calculation from 96% to 99%
- Based on growth from 110GB in early 2024 to likely 200GB+ in 2025
- Update prune size from 2GB to 2.2GB throughout docs
- Change prune=2000 to prune=2200 to match make dogecoin-config
- Update wallet name to mps_wallet to match actual configuration
- Remove 'Automated Health Checks' section - redundant with make commands
- Simplify recovery procedures to match Dogecoin documentation style
- Remove bash script examples and implementation details
- Keep focus on essential backup/recovery information
- Replace Python validation functions with simple descriptions
- Keep validation rules (D prefix, 34 chars for DOGE; 4 prefix, 95/106 chars for XMR)
- Documentation should describe what, not show implementation how
- Replace manual installation steps with make install-dogecoin
- Replace manual configuration with make dogecoin-config
- Remove raw dogecoin-cli commands in favor of make targets
- Keep documentation focused on what users need to do, not implementation details
- Multi-node setups would cause account index mismatches
- Monero wallets can't be sharded or load balanced
- Replace with honest scaling limitations and realistic options
- Single wallet file is a fundamental architectural constraint
- Document actual resource requirements from production systems
- Fix fee documentation: fee buffers are for quotes, not wallet reserves
- Clarify perfect accounting to quote amounts in atomic units
- Remove generic curl/API tutorials, keep Make commands
- Add dust prevention benefit of exact amount sweeping
- Update Makefile targets to match what actually exists
- Remove error messages from sweep/sweep-check Makefile targets
- Keep commands functional for developers/admins in local environments
- Simplify documentation to focus on automatic sweeping behavior
- Maintain separation between end-user docs and dev tools
- Update test_handle_invoice_deletion_failure to mock centralized log instance
- Change from mocking logger.error to log.error_with_context
- Test now properly validates centralized logging system usage
- Remove logging statements that exposed RPC username and password info
- Fix sweep restocking fee tests to work with centralized logging
- Update test mocking to use module-level log instance instead of class
- Maintain security by preventing credential leakage in logs
Infrastructure improvements:
- Add CryptoWatcherLogger class with centralized logging methods
- Add comprehensive __str__ and __repr__ methods to CryptoPayment model
- Include user display name and shop name in payment logs
Logging refactoring:
- Convert 101+ logger calls to use centralized patterns
- Replace repetitive f-string patterns with payment object logging
- Add standardized methods for state transitions, refunds, sweeps
- Eliminate duplicate payment context formatting
DRY improvements:
- Single point of control for payment log formatting
- Consistent error handling with payment context
- Standardized transaction and operation logging
- Enhanced debugging with rich payment information
Testing:
- Add 16 comprehensive unit tests for string representation methods
- Test coverage for all payment states and edge cases
- Maintain 100% functionality with improved maintainability
Shop owners can no longer remove/clear their cryptocurrency cold wallet
addresses once set. They can only:
1. Replace the address with a new one
2. Disable the cryptocurrency entirely (address is preserved)
Changes:
- Added server-side validation in crypto_processor_settings view
- Check if processor exists with sweep_to_address before allowing empty submission
- Show clear error message if attempt to clear address
- Updated template to add 'required' attribute when address exists
- Added user-facing note explaining the restriction
This prevents accidental or intentional removal of cold wallet addresses
which could lead to funds being stuck in the hot wallet without a way
to sweep them to cold storage.
Integration test fixes:
- Replace hardcoded status strings with proper CryptoPayment constants
- Fixed test_complete_refund_states_delete_invoice to use:
- STATUS_LATEPAY_REFUNDED_COMPLETE
- STATUS_UNDERPAID_REFUNDED_COMPLETE
- STATUS_OUT_OF_STOCK_REFUNDED_COMPLETE
- Fixed test_no_refund_payment_deletes_invoice to use STATUS_LATEPAY_NOT_REFUNDED
- Updated all other status references to use constants instead of strings
The integration tests were failing because they used hardcoded strings like
"expired-refunded-complete" instead of the actual status constants from the model.
This caused the should_keep_invoice() logic to not work properly since the
status matching failed.
Documentation updates:
- Corrected "received" state description: detected in mempool (not blockchain)
- Added clarification about confirmations tracking via current_confirmations field
- Updated mempool detection rule explanation
All 11 invoice deletion integration tests now pass, confirming the invoice
deletion logic works correctly with real database operations.
Major fixes:
1. Remove invalid received→expired transition
- Payments that reach 'received' state cannot expire
- Only pending payments can expire
- Updated VALID_TRANSITIONS and tests accordingly
2. Rename STATUS_DOUBLEPAY_REFUND to STATUS_DOUBLEPAY_REFUNDED
- Maintains consistency with all other past-tense status names
- Updated all references across codebase and tests
3. Add INITIAL_WAITING_STATUSES semantic group
- Groups states that are entry points: pending, latepay_refunded, doublepay_refunded
- These states don't transition from 'received' - they represent initial states
- Added is_initial_waiting_state() helper method
4. Update semantic groups
- Removed latepay_refunded and doublepay_refunded from FAILED_PAYMENT_STATUSES
- These are now in INITIAL_WAITING_STATUSES as they represent entry points
5. Fix mermaid diagram label
- confirmed_overpay_not_refunded now correctly labeled as "Terminal Success (Not Refunded)"
- Remove invalid received→expired transition from documentation
This improves the logical consistency of the state machine and aligns
the naming conventions across all status constants.
All invoice deletion tests were failing because they were missing the
mock setup for should_keep_invoice.return_value = False. This caused
the deletion logic to be skipped since the function would return early
when should_keep_invoice() returned the default MagicMock() value.
Changes:
- Added self.mock_crypto_payment.should_keep_invoice.return_value = False
to test_handle_invoice_deletion_returns_false test
- All 11 invoice deletion tests now pass
- Completes the crypto payment test suite fixes (155 tests passing)
The invoice deletion logic properly checks should_keep_invoice() which
returns payment.is_successful_payment(), and failed payments should
have their invoices deleted while successful payments should keep them.
When multiple transactions arrive simultaneously to a pending payment, treat ALL transactions as duplicates rather than processing the first one normally. This prevents potential attack scenarios where multiple payments are sent rapidly to the same quote.
- Modified duplicate detection logic to treat all concurrent transactions as suspicious
- Set new_sum=0 and new_txids=[] when all transactions become duplicates
- Removed recalculation logic that was processing first transaction
- Enhanced logging to reflect new behavior
Fixes test_double_spend_protection.py failures. All 130 crypto tests now pass.
- Fix duplicate detection logic to prevent amount accumulation when new transactions arrive to already-processed payments
- Fix status constant naming errors: STATUS_CONFIRMED_OVERPAID → STATUS_CONFIRMED_OVERPAY, STATUS_EXPIRED_REFUNDED → STATUS_LATEPAY_REFUNDED
- Fix SweepRestockingFeeTests mock setup: add missing refund_confirmations, get_coin_config patches, and proper XMR client mocks
- Correct overpayment test expectations: restocking fee sweep happens later after refund confirmation, not immediately
- Update test assertions to match actual implementation behavior (transfer vs sweep_all for XMR)
- Add comprehensive mock configurations for DOGE/XMR atomic units and balance methods
All 108 crypto payment tests now pass. Fixes critical duplicate payment processing bug and aligns test expectations with production behavior.
* Implement complete state machine with 17 test scenarios
* Add priority-based processing order validation
* Include property-based testing for state transitions
* Add graph analysis for state machine integrity
* Validate all payment lifecycle paths
* Ensure robust error handling and logging
* Remove temporary debug files and consolidate test structure
- Fix payment_priority() to include ALL refund statuses (EXPIRED_REFUNDED, UNDERPAID_REFUNDED, OUT_OF_STOCK_REFUNDED) not just DOUBLEPAY_REFUND
- Auto-sweep operations (CONFIRMED, CONFIRMED_OVERPAID, NO_REFUND) now have lowest priority (3)
- Refactor to use match/case statements for better readability
- Add comprehensive docstring explaining priority system
- Ensure refunds processed before auto-sweep for customer service priority
Priority order: 0=refunds, 1=incoming, 2=other (pending/terminals), 3=auto-sweep
Updated tests to reflect correct behavior where multiple transactions
to one quote are treated as duplicates rather than legitimate payments.
Key changes:
- Fixed test_concurrent_transactions_within_processing_window to expect
duplicate detection behavior instead of transaction summing
- Fixed test_second_processing_cycle_rejects_duplicates to properly
validate duplicate detection warnings and status
- Updated test_multiple_rapid_payments_scenario and test_zero_amount_transactions
to handle duplicate payment scenarios correctly
- Removed int() casting from received_amount calculation to preserve
precision in cryptocurrency amounts
The core insight is that there should never be legitimate multiple
transactions to one quote - any additional transactions are duplicates
that should be handled by the scanner for refunds.
All 22 tests in test_double_spend_protection.py now pass.
- Add detection for multiple transactions during initial pending payment processing
- Process first transaction normally, create DOUBLEPAY_REFUND records for duplicates
- Recalculate amounts to use only first transaction for original payment
- Prevent summing all transactions into single overpayment
- Maintain existing logic for already-processed payments with new transactions
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
The issue was that duplicate payments were being created without proper
invoice references, causing the refund processing logic to fail when
looking up user information. This resulted in duplicate payments being
marked as 'no-refund' instead of 'doublepay-refund'.
Key changes:
- Modified _create_duplicate_payment() to preserve the original invoice
reference instead of setting it to None
- Updated duplicate payment processing logic to use the invoice.user
directly instead of trying to look up the "original payment"
- Explicitly set user_id and shop_id foreign keys to ensure proper
database relationships
- Updated test assertions to expect duplicate payments to reference
the same invoice as the original payment
This fixes the core architectural insight that duplicate payments
should reference the same invoice since they're all payments toward
the same original quote/order. The invoice-to-quote relationship
remains intact while allowing proper duplicate payment tracking.
Fixes:
- test_double_payment_creates_separate_refund_entry
- test_race_condition_double_refund_prevention
- test_three_payments_one_confirms_two_refund
- Fix precision mismatches by using Decimal arithmetic throughout quote generation
- Replace int() truncation with math.ceil() for atomic unit conversions
- Update DOGE and XMR quote generation to avoid floating point errors
- Fix order of operations: process duplicate refunds BEFORE auto-sweep
- Add fund reservation logic to auto-sweep to protect pending refunds
- Fix duplicate payment queries to use address for DOGE, subaddress for XMR
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
