Skip to content

Feat/sslcommerz integration#2

Open
tenbytecloud wants to merge 11 commits intoflexprice_v1.0.47from
feat/sslcommerz-integration
Open

Feat/sslcommerz integration#2
tenbytecloud wants to merge 11 commits intoflexprice_v1.0.47from
feat/sslcommerz-integration

Conversation

@tenbytecloud
Copy link
Copy Markdown

@tenbytecloud tenbytecloud commented Jan 21, 2026

  1. Configuration - Added SSLCommerz config with session API, validation API, IPN URL, and redirect URLs
  2. Client - SSLCommerz API client for creating payment sessions and validating payments
  3. Payment Service - Creates payment links via SSLCommerz API
  4. Webhook Handler - Handles IPN callbacks from SSLCommerz
  5. Connection Metadata - SSLCommerz credentials (store_id, store_password) stored encrypted in connections table
  6. Integration Factory - SSLCommerz integration wired into the factory pattern

Disclaimer: This comment was generated by Greptile AI CTO

Greptile Summary

Adds SSLCommerz payment gateway for Bangladesh market with session-based payment links, IPN webhook validation, and encrypted credential storage. Implementation follows existing payment gateway patterns (Stripe, Razorpay) with proper separation of concerns.

Key Changes:

  • SSLCommerz client with session creation and order validation APIs
  • Payment link generation with invoice validation and customer fallbacks
  • IPN webhook with background processing and panic recovery
  • Connection metadata stored encrypted in database (not config)
  • CORS middleware fixed to use origin whitelist instead of echo-all
  • Wallet transaction balance tracking fields added

Critical Issues:

  • Webhook goroutine race condition: duplicate IPNs can process same payment concurrently
  • Background context timeout could cause silent failures after 200 OK response

Architecture Decisions:

  • Using payment ID as transaction ID eliminates collision risks
  • Risk level 1 payments blocked by default (needs business decision on fraud tolerance)
  • Customer service failures handled gracefully with defaults

Confidence Score: 3/5

  • Safe for tight-deadline launch but has race condition risk from concurrent webhook processing
  • Score reflects solid architecture and security (encrypted credentials, validation API) but webhook race condition and context timeout are deployment risks. For MVP launch, acceptable if you monitor failed webhooks and can reprocess manually. For production scale, fix race condition with payment locking or idempotency.
  • Pay close attention to internal/integration/sslcommerz/webhook/handler.go and internal/api/v1/webhook.go for race conditions and timeout handling

Important Files Changed

Filename Overview
internal/integration/sslcommerz/client.go SSLCommerz API client for session creation and validation - clean implementation with proper encryption handling
internal/integration/sslcommerz/payment.go Payment link creation and reconciliation logic - solid validations and fallback handling for customer data
internal/integration/sslcommerz/webhook/handler.go IPN webhook handler with validation API call - handles async processing correctly but has timeout context concerns
internal/api/v1/webhook.go Added SSLCommerz webhook endpoint with goroutine processing and panic recovery - follows existing patterns
internal/service/payment_processor.go Integrated SSLCommerz payment link creation into payment processor - follows existing gateway pattern

srtenbyte and others added 4 commits January 7, 2026 02:00
- fix cors issue
- fix wallet tx issue
- fix field missing issue
   - Add SSLCommerz client with session API and validation API support
   - Add payment service for creating SSLCommerz payment links
   - Add webhook handler for IPN callbacks
   - Add SSLCommerz configuration in config.go and config.yaml
   - Add SSLCommerz connection metadata types
   - Add SSLCommerz case in connection repository for metadata conversion
   - Add SSLCommerz payment gateway type and secret provider
   - Integrate SSLCommerz in payment processor service
@tenbytecloud
Copy link
Copy Markdown
Author

@greptileai review

@tenbytecloud
Copy link
Copy Markdown
Author

@greptileai review

@tenbytecloud
Copy link
Copy Markdown
Author

@greptileai review all the files of this PR only, stop the previous work of yours

Copy link
Copy Markdown

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Additional Comments (3)

  1. internal/domain/subscription/model.go, line 147-220 (link)

    logic: Missing InvoiceCadence field in conversion function. This will cause data loss when converting from database entities.

  2. internal/domain/wallet/transaction.go, line 57-84 (link)

    logic: Missing BalanceBefore and BalanceAfter fields in ToEnt() conversion. These should be mapped to maintain data consistency between domain and entity layers.

  3. internal/domain/wallet/transaction.go, line 88-122 (link)

    logic: Missing BalanceBefore and BalanceAfter fields in FromEnt() conversion. Add mappings for these fields to prevent data loss during entity-to-domain conversion.

39 files reviewed, 16 comments

Edit Code Review Agent Settings | Greptile

srtenbyte and others added 4 commits January 22, 2026 14:11
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
  SSLCommerz improvements:
  - Use PaymentID as TranID for unique transaction identification
  - Update webhook handler to lookup payments by PaymentID
  - Remove redundant GatewayPageURL field from response DTO
  - Fix BaseFair -> BaseFare spelling in validation response

  Security enhancements:
  - Add CORS origin whitelisting with configurable allowed_origins
  - Remove store credentials from config (use Connection API instead)
  - Remove seed script in favor of POST /connections endpoint

  Code cleanup:
  - Separate error handling for service errors vs empty results
  - Remove unused SSLCommerz flags from scripts/main.go
  - Add InvoiceCadence field mapping in GetSubscriptionFromEnt()
  - Add balance_before and balance_after fields to wallet transaction:
    - Update ent schema with new decimal fields
    - Update ToEnt() and FromEnt() conversion functions
    - Add V5 migration files (up/down) for new columns
@tenbytecloud
Copy link
Copy Markdown
Author

@greptileai review last 3 commits

Copy link
Copy Markdown

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

46 files reviewed, 3 comments

Edit Code Review Agent Settings | Greptile

Comment on lines +85 to +99
if ipnData.RiskLevel == "1" && ipnData.Status == "VALID" {
h.logger.Warnw("SSLCommerz payment is VALID but risk_level=1, holding for manual verification",
"tran_id", ipnData.TranID,
"val_id", ipnData.ValID,
"risk_level", ipnData.RiskLevel)

err = h.updatePaymentStatus(ctx, ipnData, "PENDING_VERIFICATION",
lo.ToPtr("Payment is valid but risk level is high; manual verification required."),
services)
if err != nil {
h.logger.Errorw("failed to update payment status for high-risk transaction",
"error", err,
"tran_id", ipnData.TranID)
}
return nil
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

style: Risk_level=1 with VALID status means "high risk but payment cleared." SSLCommerz docs say you CAN accept these after manual review. Current logic blocks ALL risk_level=1 automatically.

For tight deadlines, consider: if business accepts the fraud risk, remove this block and log warning only. If manual review required, ensure someone monitors these PENDING_VERIFICATION payments.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Prompt To Fix With AI
This is a comment left during a code review.
Path: internal/integration/sslcommerz/webhook/handler.go
Line: 85:99

Comment:
**style:** Risk_level=1 with VALID status means "high risk but payment cleared." SSLCommerz docs say you CAN accept these after manual review. Current logic blocks ALL risk_level=1 automatically. 

For tight deadlines, consider: if business accepts the fraud risk, remove this block and log warning only. If manual review required, ensure someone monitors these PENDING_VERIFICATION payments.

<sub>Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!</sub>

How can I resolve this? If you propose a fix, please make it concise.

# Redirect URLs after payment
success_url: "https://seedless-garishly-ahmed.ngrok-free.dev/payment/success"
fail_url: "https://seedless-garishly-ahmed.ngrok-free.dev/payment/fail"
cancel_url: "https://seedless-garishly-ahmed.ngrok-free.dev/payment/cancel" No newline at end of file
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need these here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants