# Postmortem: Payment Integration Failure Due to Unavailable Sham Cash Flutter SDK
## Summary
- Attempted to integrate Sham Cash payment functionality into a Flutter app
- Assumed existence of official SDK based on industry-standard providers
- Discovered post-development that Sham Cash lacks public API/SDK documentation
- Integration stalled, requiring redesign and vendor change
## Root Cause
1. Assumption validation failure:
- No formal verification of Sham Cash API existence at requirement stage
- Presumption all payment providers offer SDKs matched competitor norms
2. Resource limitations:
- Sole focus on Flutter-specific solutions skipped examination of general REST API options
- Reliance on incomplete documentation scans rather than contacting provider support
3. Scope gaps:
- "Integrate Sham Cash" requirement entered backlog without feasibility validation
- Payment method selection lacked vendor capability assessment
## Why This Happens in Real Systems
- **Payment provider fragmentation**: Smaller providers lack resources for multi-platform SDKs
- **Time pressure**: Feature timelines discourage exhaustive vendor research
- **Confirmation bias**: Engineers subconsciously ignore contrary evidence when expecting industry-standard solutions
- **Documentation gaps**: Payment providers often prioritize enterprise sales over public docs
## Real-World Impact
- **Timeline disruption**: 3-week delay launching payment features
- **Resource waste**: 80 developer-hours spent on integration attempts
- **Contract risks**: Violated SLAs with launch partners
- **User experience impact**: Required removal of Sham Cash from marketing materials
- **Refactoring costs**: Rewrote payment module to support fallback provider
## Example or Code
```dart
// Initial (failed) Flutter SDK integration approach
import 'package:sham_cash_sdk/sham_cash.dart'; // Non-existent package
class PaymentService {
Future<void> processShamCashPayment() async {
try {
await ShamCashSDK.init(apiKey: 'API_KEY'); // Would fail during compilation
ShamCashSDK.processPayment(amount: 100);
} catch (e) {
// Unreachable error handling
}
}
}
How Senior Engineers Fix It
- Vendor validation first:
- Contact provider sales/support for integration options before coding
- Verify SDK existence through official channels (not just docs)
- Architectural fallbacks:
- Build payment abstraction layer supporting multiple providers
- Implement feature flags for payment methods
- Proof-of-concept sprint:
- Create spike to validate integration feasibility
- Test redirect flows using deep links before SDK implementation
- Terraform documentation:
PAYMENT PROVIDER CHECKLIST
- [ ] Official SDK exists (GitHub/package manager)
- [ ] Public REST API documented
- [ ] Sandbox environment available
- [ ] Support contact confirmed integration path
Why Juniors Miss It
- Tooling expectations: Assume all popular services have SDKs matching Stripe/PayPal
- Documentation literalism: Stop when SDK mention absent from main docs page
- Solution jumping: Prefer SDK implementation over REST/redirect workarounds
- Authority deference: Trust product requirements without technical validation
- Asking hesitation: Delay contacting vendors/seniors fearing “obvious” questions