Stage 1
Fund or receive
- Bank
- Card
- External wallet
- Another GivPay user
- Existing balance
- Business payment
How GivPay works
One simple action for the user. One coordinated route behind it.
The user chooses what they want to do. GivPay coordinates the eligible wallets, stablecoins, chains, conversion paths, providers and delivery methods required to complete the payment.
Personal, Merchant and Business flows are currently demonstrated in the working GivPay prototype. API and SDK access is planned.
The universal flow
From intent to an eligible outcome.
GivPay finds the most efficient eligible route from funding or receipt to holding, payment or final delivery.
Stage 2
InfrastructureGivPay Core
- Understand the payment intent
- Determine transaction eligibility
- Construct the execution route
- Coordinate every required leg
- Maintain transaction state
- Recover, fall back and verify
Stage 3
Hold, use or deliver
- Hold stable value
- Send to a person
- Pay a merchant
- Pay a supplier
- Transfer to an external wallet
- Convert to local currency
- Receive through a claim link
GivPay owns the payment intent, route construction, transaction state, fallback, recovery and final outcome verification. Infrastructure providers execute individual legs of the route.
The destination does not always need to be an off-ramp. Value may remain available for future use.
What happens behind the scenes?
- Wallet authorization
- Stablecoin rail
- Blockchain network
- Liquidity and conversion
- Provider availability
- KYC or KYB provider requirements
- Transaction state
- Fallback
- Reconciliation
GivPay is Solana-first, not Solana-only, and the infrastructure is not intended to depend on one network forever.
Open by design
Open on-chain. Open to the world.
GivPay is designed to remove two different forms of payment lock-in.
Open execution
GivPay currently starts with Solana for on-chain execution. Its architecture is designed to expand across additional chains and payment rails over time, without becoming dependent on one network, one provider or a closed internal ledger.
Open receiving
Claim links open GivPay receiving to anyone, anywhere in the world.
The recipient does not need to already be a GivPay user, have a crypto wallet or provide a predefined destination before the payment is created. The sender generates a claim link and can share it with any intended recipient.
The recipient opens the same universal access point, selects their country and then chooses an eligible way to receive or use the value.
The orchestration layer opens GivPay across on-chain infrastructure. Claim links open GivPay beyond its existing user network, making anyone in the world a potential recipient.
The claim link itself is globally accessible by design. The availability of local fiat on-ramp and off-ramp methods used to fund or cash out the payment may depend on geography, provider coverage and compliance eligibility.
Personal
PrototypeFund or receive → hold stable value → send, pay or withdraw
- 01
Fund or receive
Receive from another user, open a claim link, use an eligible funding method or receive from an external wallet.
- 02
Hold
Keep value available in supported stablecoins without managing chains or gas directly.
- 03
Use
Send to another person, pay a merchant or transfer to an external wallet.
- 04
Withdraw
Convert through an eligible local method only when local currency is required.
Send beyond the GivPay network
Sender creates the payment → recipient opens the link → recipient selects their country → recipient chooses how to receive
The intended recipient can be anyone in the world and does not need to already have a GivPay account or crypto wallet. The first screen only communicates that money has been received. A localized value appears after country selection, and conversion or off-ramp begins only after the recipient selects and confirms an eligible receiving method.
Merchant
PrototypeAccept payment → receive value → keep, reuse or settle
- 01
Accept
Accept through QR, payment link or a supported wallet-based payment flow.
- 02
Receive
Receive the payment through the same GivPay infrastructure used by other modes.
- 03
Keep or reuse
Retain supported stablecoin value for future merchant or business payments where available.
- 04
Settle
Convert through an eligible local route when local currency is required.
Merchant payments should feel familiar to the payer even when stablecoin rails are used behind the experience.
Business
PrototypeFund or receive → pay suppliers or make payouts → retain or convert
- 01
Fund or receive
Receive an international business payment or fund through an eligible source.
- 02
Pay
Pay suppliers, contractors or other businesses through one coordinated payment flow.
- 03
Distribute
Initiate individual or recurring payouts where represented in the prototype.
- 04
Retain or convert
Keep supported stablecoin balances for future operations or convert only the amount needed locally.
A business may receive stable value, pay a supplier from the same balance and off-ramp only the amount needed for local expenses.
Planned
The same infrastructure, integrable later
Future APIs and SDKs will allow external products to integrate selected GivPay capabilities without rebuilding the full payment path themselves.
External product
GivPay Core
Eligible payment outcome
Why orchestration matters
No single route works for every payment.
No single provider, rail or delivery method is suitable for every payment. GivPay constructs and coordinates the eligible execution route based on geography, transaction requirements, availability, limits, cost, speed and reliability.
The route is not selected only by price.
GivPay optimizes each payment to maximize the value that reaches the recipient, minimize the time until funds are actually usable, and avoid unnecessary fees, conversions, execution steps and failed routes.