Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Implement Flexible Payment Flow for DVM Service Providers #7

Open
AbdelStark opened this issue Jul 30, 2024 · 0 comments
Open

Comments

@AbdelStark
Copy link
Owner

Description

We need to implement a flexible payment flow for Data Vending Machine (DVM) service providers, allowing them to optionally request payment upfront or after job completion. This implementation should follow the NIP-90 DVM flow and integrate with NIP-57 for Lightning Zaps.

Requirements

  1. Service provider configuration:

    • Add a configuration option for each service provider to specify their preferred payment flow:
      • Upfront payment required
      • Payment after job completion
      • Flexible (allow both options)
  2. Job request handling:

    • When receiving a job request (kind: 5600), check the service provider's payment configuration.
    • If upfront payment is required, send a kind: 7000 job feedback event with status: "payment-required" before processing the job.
  3. Payment flow:

    • Implement NIP-57 Lightning Zaps for payment processing.
    • For upfront payments:
      • Include an amount tag in the kind: 7000 job feedback event.
      • Wait for payment confirmation before proceeding with job processing.
    • For payment after job completion:
      • Include an amount tag in the kind: 6600 job result event.
      • Optionally send a kind: 7000 job feedback event with status: "payment-required" after delivering results.
  4. Payment verification:

    • Implement a system to verify Lightning Zap receipts (kind: 9735) as described in NIP-57.
    • Ensure that the payment amount matches the requested amount in the job feedback or job result event.
  5. Job processing:

    • For upfront payments: Begin processing the job only after payment confirmation.
    • For payment after job completion: Deliver results and then request payment.
  6. Error handling:

    • Implement proper error handling for payment-related issues (e.g., insufficient payment, payment timeout).
    • Send appropriate kind: 7000 job feedback events with status: "error" and relevant error messages.
  7. Partial results and progressive payments:

    • Consider implementing support for partial results and progressive payments for long-running jobs.
    • Use kind: 7000 job feedback events with status: "partial" to deliver partial results and request progressive payments.

Implementation Steps

  1. Update the service provider configuration schema to include payment flow preferences.
  2. Modify the job request handler to check payment configuration and send appropriate feedback events.
  3. Implement NIP-57 Lightning Zaps integration for payment processing.
  4. Create a payment verification system for Lightning Zap receipts.
  5. Update the job processing flow to accommodate both upfront and post-completion payment scenarios.
  6. Implement error handling for payment-related issues.
  7. (Optional) Develop support for partial results and progressive payments.

Testing

  1. Create test cases for different payment flow configurations.
  2. Test upfront payment scenarios, ensuring job processing only begins after payment confirmation.
  3. Test payment after job completion scenarios, verifying result delivery and subsequent payment request.
  4. Verify proper handling of payment errors and edge cases.
  5. Test partial results and progressive payments (if implemented).

Documentation

  1. Update service provider documentation to explain the new payment flow options.
  2. Create user documentation explaining the different payment scenarios they may encounter.
  3. Document the integration with NIP-57 Lightning Zaps for developers.

Related NIPs

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

No branches or pull requests

1 participant