Subscription / payment screen #1476

New Issue

2019-06-29T13:12:31+02:00

PeterSurda commented

2019-06-29 13:12:31 +02:00

(Migrated from github.com)

There should be a payment wizard for the subscription / payment, shown when people click on "Subscription / payment" in the kivy UI. This is the first iteration so it may change in the future. On the low level blind signatures will be used (#1409)

information about what it is for, and a choice between 100 credits and 500 credits. Selecting one will bring you to second page
choice of a distributor (at the begining, Bitmessage GmbH)
choice of a payment method (at the beginning, we can have bitcoin testnet, litecoin and bitcoin cash main net).
payment-specific handling. For cryptocurrencies, there can be new extended encoding type(s) for order and payment request. An example of the workflow, see https://github.com/PeterSurda/bitmessage-email-gateway. For other payments, maybe a redirect to a website or something.
for handling blind signatures, use dummy functions
store received credits (certified signatures) in messages.dat, so there needs to be a new table

There should be a section in the keys.dat determining which payment methods and distributors are available. There should also be a separate bitmessage account hidden from the UI for handling payment communications.

There also needs to be a backend counterpart. I'm not sure yet whether this will be a separate project using an API, or a bitmessage module using extended encoding.

There should be a payment wizard for the subscription / payment, shown when people click on "Subscription / payment" in the kivy UI. This is the first iteration so it may change in the future. On the low level blind signatures will be used (#1409) 1. information about what it is for, and a choice between 100 credits and 500 credits. Selecting one will bring you to second page 2. choice of a distributor (at the begining, Bitmessage GmbH) 3. choice of a payment method (at the beginning, we can have bitcoin testnet, litecoin and bitcoin cash main net). 4. payment-specific handling. For cryptocurrencies, there can be new extended encoding type(s) for order and payment request. An example of the workflow, see https://github.com/PeterSurda/bitmessage-email-gateway. For other payments, maybe a redirect to a website or something. 5. for handling blind signatures, use dummy functions 6. store received credits (certified signatures) in messages.dat, so there needs to be a new table There should be a section in the keys.dat determining which payment methods and distributors are available. There should also be a separate bitmessage account hidden from the UI for handling payment communications. There also needs to be a backend counterpart. I'm not sure yet whether this will be a separate project using an API, or a bitmessage module using extended encoding.

This repo is archived. You cannot comment on issues.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Bitmessage/PyBitmessage-2025-02-17#1476