All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog.
- Add sorting to
GET /users
endpoint #104
- Update log message for better debugging. #125
- Fix client_domain from the Viobrant Assist wallet. #126
- API endpoints for managing Wallet Providers:
- Introduced metrics and Grafana dashboard for monitoring payment transactions in TSS. #21
- TSS documentation. #25
- Phone number validation before sending OTP. #38
- Add Vibrant Assist RC to the list of supported wallets in pubnet #43
- Store Anchor Platform transaction ID in the database when registering a new receiver. #44
- Documentation for
CRASH_TRACKER_TYPE
env variable. #49 - Add a job to periodically sync the transaction status back to the Anchor Platform #55
- Introduce a retry mechanism for SMS invitations. #60
- Add proper error messages when receiver exceeds the maximum number of attempts to validate their PII. #62
- Add validation and flags to countries dropdown during receiver registration. #33
- Update transaction worker to use Crash Tracker on failed transactions #39
- Increase the default maximum number of attempts for a receiver to validate their PII. #56
- Prevent users from deactivating their own accounts. #58
- Stop enforcing ECDSA only and allow any EC public/private keys at least as strong as EC256 #61
- Refactor SMS invitation service #66
- Removed the environment variables
MAX_RETRIES
andMIN_DAYS_BETWEEN_RETRIES
. - Added the environment variable
MAX_INVITATION_SMS_RESEND_ATTEMPTS
to control the maximum number of attempts to send an SMS invitation. The default value is 3.
- Removed the environment variables
- API Tweaks:
- Stellar.Expert URL in env-config.js for dev environment setup. #34
- Patch the correct transaction data fields in AnchorPlatform. #40
- Sep10 domain configuration for Vibrant wallet on Testnet. #42
- The SMS invitation link for XLM asset. #46
- Added application activity logs for account lifecycle, password management and user access patterns. #29
- Support to XLM disbursements. #1
- Helm chart documentation. #9
PATCH /profile/reset-password
endpoint to reset the password. #18
- Helmchart changes:
- Default
MAX_BASE_FEE
is now higher, to prevent low-fee error responses. #8 - Changed job frequency for more real-time updates. #12
- Change OTP message for better UX. #23
- API tweaks:
- TSS Channel Account management commands now can handle parallel calls. #6
- Horizon error parsing to use the default
HorizonErrorWrapper
class. #13 - API response that should be 401 instead of 500. #14
- Removed CLI flag that could disable private key encryption in the database. $24
- Add job to periodically check if the AP is auth protected. #10
- Add stronger password validation throughout the project. #22
First Release Candidate of the Stellar Disbursement Platform, a tool used to make bulk payments to a list of recipients based on their phone number and a confirmation date. This repository is backend-only, and the frontend version can be found at stellar/stellar-disbursement-platform-frontend. Their version numbers are meant to be kept in sync.
The basic process of this product starts with an organization supplying a CSV file which includes the recipients' phone number, transfer amount, and essential customer validation data such as the date of birth.
The platform subsequently sends an SMS to the recipient, which includes a deep link to the wallet. This link permits recipients with compatible wallets to register their wallet on the SDP. During this step, they are required to verify their phone number and additional customer data through the SEP-24 interactive deposit flow, where this data is shared directly with the backend through a webpage inside the wallet, but the wallet itself does not have access to this data.
Upon successful verification, the SDP will transfer the funds directly to the recipient's wallet. When the recipient's wallet has been successfully associated with their phone number in the SDP, all subsequent payments will occur automatically.