2019-10-17 15:04:50 +01:00
|
|
|
// Copyright (C) 2019 Storj Labs, Inc.
|
|
|
|
// See LICENSE for copying information.
|
|
|
|
|
|
|
|
package payments
|
|
|
|
|
|
|
|
import (
|
|
|
|
"context"
|
|
|
|
"time"
|
|
|
|
|
satellite/payments: specialized type for monetary amounts
Why: big.Float is not an ideal type for dealing with monetary amounts,
because no matter how high the precision, some non-integer decimal
values can not be represented exactly in base-2 floating point. Also,
storing gob-encoded big.Float values in the database makes it very hard
to use those values in meaningful queries, making it difficult to do
any sort of analysis on billing.
For better accuracy, then, we can just represent monetary values as
integers (in whatever base units are appropriate for the currency). For
example, STORJ tokens or Bitcoins can not be split into pieces smaller
than 10^-8, so we can store amounts of STORJ or BTC with precision
simply by moving the decimal point 8 digits to the right. For USD values
(assuming we don't want to deal with fractional cents), we can move the
decimal point 2 digits to the right.
To make it easier and less error-prone to deal with the math involved, I
introduce here a new type, monetary.Amount, instances of which have an
associated value _and_ a currency.
Change-Id: I03395d52f0e2473cf301361f6033722b54640265
2021-08-10 23:29:50 +01:00
|
|
|
"github.com/shopspring/decimal"
|
|
|
|
|
2020-03-30 10:08:50 +01:00
|
|
|
"storj.io/common/uuid"
|
2022-04-28 03:54:56 +01:00
|
|
|
"storj.io/storj/private/blockchain"
|
satellite/payments: specialized type for monetary amounts
Why: big.Float is not an ideal type for dealing with monetary amounts,
because no matter how high the precision, some non-integer decimal
values can not be represented exactly in base-2 floating point. Also,
storing gob-encoded big.Float values in the database makes it very hard
to use those values in meaningful queries, making it difficult to do
any sort of analysis on billing.
For better accuracy, then, we can just represent monetary values as
integers (in whatever base units are appropriate for the currency). For
example, STORJ tokens or Bitcoins can not be split into pieces smaller
than 10^-8, so we can store amounts of STORJ or BTC with precision
simply by moving the decimal point 8 digits to the right. For USD values
(assuming we don't want to deal with fractional cents), we can move the
decimal point 2 digits to the right.
To make it easier and less error-prone to deal with the math involved, I
introduce here a new type, monetary.Amount, instances of which have an
associated value _and_ a currency.
Change-Id: I03395d52f0e2473cf301361f6033722b54640265
2021-08-10 23:29:50 +01:00
|
|
|
"storj.io/storj/satellite/payments/monetary"
|
2019-10-17 15:04:50 +01:00
|
|
|
)
|
|
|
|
|
|
|
|
// StorjTokens defines all payments STORJ token related functionality.
|
2020-01-29 00:57:15 +00:00
|
|
|
//
|
|
|
|
// architecture: Service
|
2019-10-17 15:04:50 +01:00
|
|
|
type StorjTokens interface {
|
2019-11-21 14:25:37 +00:00
|
|
|
// Deposit creates deposit transaction for specified amount in cents.
|
|
|
|
Deposit(ctx context.Context, userID uuid.UUID, amount int64) (*Transaction, error)
|
2020-05-28 12:31:02 +01:00
|
|
|
// ListTransactionInfos returns all transactions associated with user.
|
2019-11-12 11:14:34 +00:00
|
|
|
ListTransactionInfos(ctx context.Context, userID uuid.UUID) ([]TransactionInfo, error)
|
2020-05-28 12:31:02 +01:00
|
|
|
// ListDepositBonuses returns all deposit bonuses associated with user.
|
|
|
|
ListDepositBonuses(ctx context.Context, userID uuid.UUID) ([]DepositBonus, error)
|
2019-10-17 15:04:50 +01:00
|
|
|
}
|
|
|
|
|
2022-04-28 03:54:56 +01:00
|
|
|
// DepositWallets exposes all needed functionality to manage token deposit wallets.
|
|
|
|
//
|
|
|
|
// architecture: Service
|
|
|
|
type DepositWallets interface {
|
|
|
|
// Claim gets a new crypto wallet and associates it with a user.
|
|
|
|
Claim(ctx context.Context, userID uuid.UUID) (blockchain.Address, error)
|
|
|
|
// Get returns the crypto wallet address associated with the given user.
|
|
|
|
Get(ctx context.Context, userID uuid.UUID) (blockchain.Address, error)
|
|
|
|
}
|
|
|
|
|
2019-10-17 15:04:50 +01:00
|
|
|
// TransactionStatus defines allowed statuses
|
|
|
|
// for deposit transactions.
|
|
|
|
type TransactionStatus string
|
|
|
|
|
2019-11-12 11:14:34 +00:00
|
|
|
// String returns string representation of transaction status.
|
|
|
|
func (status TransactionStatus) String() string {
|
|
|
|
return string(status)
|
|
|
|
}
|
|
|
|
|
2019-10-17 15:04:50 +01:00
|
|
|
const (
|
|
|
|
// TransactionStatusPaid is a transaction which successfully received required funds.
|
|
|
|
TransactionStatusPaid TransactionStatus = "paid"
|
|
|
|
// TransactionStatusPending is a transaction which accepts funds.
|
|
|
|
TransactionStatusPending TransactionStatus = "pending"
|
|
|
|
// TransactionStatusCancelled is a transaction that is cancelled and no longer accepting new funds.
|
|
|
|
TransactionStatusCancelled TransactionStatus = "cancelled"
|
|
|
|
)
|
|
|
|
|
|
|
|
// TransactionID is a transaction ID type.
|
|
|
|
type TransactionID []byte
|
|
|
|
|
2019-11-12 11:14:34 +00:00
|
|
|
// String returns string representation of transaction id.
|
|
|
|
func (id TransactionID) String() string {
|
|
|
|
return string(id)
|
|
|
|
}
|
|
|
|
|
2019-10-17 15:04:50 +01:00
|
|
|
// Transaction defines deposit transaction which
|
|
|
|
// accepts user funds on a specific wallet address.
|
|
|
|
type Transaction struct {
|
|
|
|
ID TransactionID
|
satellite/payments: specialized type for monetary amounts
Why: big.Float is not an ideal type for dealing with monetary amounts,
because no matter how high the precision, some non-integer decimal
values can not be represented exactly in base-2 floating point. Also,
storing gob-encoded big.Float values in the database makes it very hard
to use those values in meaningful queries, making it difficult to do
any sort of analysis on billing.
For better accuracy, then, we can just represent monetary values as
integers (in whatever base units are appropriate for the currency). For
example, STORJ tokens or Bitcoins can not be split into pieces smaller
than 10^-8, so we can store amounts of STORJ or BTC with precision
simply by moving the decimal point 8 digits to the right. For USD values
(assuming we don't want to deal with fractional cents), we can move the
decimal point 2 digits to the right.
To make it easier and less error-prone to deal with the math involved, I
introduce here a new type, monetary.Amount, instances of which have an
associated value _and_ a currency.
Change-Id: I03395d52f0e2473cf301361f6033722b54640265
2021-08-10 23:29:50 +01:00
|
|
|
Amount monetary.Amount
|
|
|
|
Rate decimal.Decimal
|
2019-11-12 11:14:34 +00:00
|
|
|
Address string
|
|
|
|
Status TransactionStatus
|
2019-11-15 14:59:39 +00:00
|
|
|
Timeout time.Duration
|
2019-12-12 13:09:19 +00:00
|
|
|
Link string
|
2019-11-12 11:14:34 +00:00
|
|
|
CreatedAt time.Time
|
|
|
|
}
|
|
|
|
|
|
|
|
// TransactionInfo holds transaction data with additional information
|
|
|
|
// such as links and expiration time.
|
|
|
|
type TransactionInfo struct {
|
2019-11-21 13:23:16 +00:00
|
|
|
ID TransactionID
|
satellite/payments: specialized type for monetary amounts
Why: big.Float is not an ideal type for dealing with monetary amounts,
because no matter how high the precision, some non-integer decimal
values can not be represented exactly in base-2 floating point. Also,
storing gob-encoded big.Float values in the database makes it very hard
to use those values in meaningful queries, making it difficult to do
any sort of analysis on billing.
For better accuracy, then, we can just represent monetary values as
integers (in whatever base units are appropriate for the currency). For
example, STORJ tokens or Bitcoins can not be split into pieces smaller
than 10^-8, so we can store amounts of STORJ or BTC with precision
simply by moving the decimal point 8 digits to the right. For USD values
(assuming we don't want to deal with fractional cents), we can move the
decimal point 2 digits to the right.
To make it easier and less error-prone to deal with the math involved, I
introduce here a new type, monetary.Amount, instances of which have an
associated value _and_ a currency.
Change-Id: I03395d52f0e2473cf301361f6033722b54640265
2021-08-10 23:29:50 +01:00
|
|
|
Amount monetary.Amount
|
|
|
|
Received monetary.Amount
|
2019-11-21 13:23:16 +00:00
|
|
|
AmountCents int64
|
|
|
|
ReceivedCents int64
|
|
|
|
Address string
|
|
|
|
Status TransactionStatus
|
|
|
|
Link string
|
|
|
|
ExpiresAt time.Time
|
|
|
|
CreatedAt time.Time
|
2019-10-17 15:04:50 +01:00
|
|
|
}
|
2019-11-12 11:14:34 +00:00
|
|
|
|
2020-05-28 12:31:02 +01:00
|
|
|
// DepositBonus defines a bonus received for depositing tokens.
|
|
|
|
type DepositBonus struct {
|
|
|
|
TransactionID TransactionID
|
|
|
|
AmountCents int64
|
|
|
|
Percentage int64
|
|
|
|
CreatedAt time.Time
|
|
|
|
}
|