Gee elke gebruiker ’n unieke kripto-deposito-adres

Waarom een gedeelde adres nie werk nie

Elke platform wat kripto aanvaar loop in dieselfde muur vas, in dieselfde volgorde, gewoonlik ná die eerste ondersteuningskaartjie oor ’n betaling wat niemand kan opspoor nie.

• ’n Enkele adres gee jou ’n bedrag en ’n sender, nooit aan watter van jou gebruikers dit behoort nie. Passing volgens bedrag breek die eerste keer dat twee mense dieselfde syfer stuur.
• Die gewone omweg is om alles saam te gooi en later uit te betaal — wat ’n betalingsfunksie in die hou van ander mense se geld verander, die swaarste ding wat ’n platform kan opneem.
• Om gebruikers te vra om ’n memo of verwysing in te plak werk totdat iemand vergeet, en dan is dit ’n mens wat ’n blokketting met die hand rekonsilieer.

Een oproep per gebruiker, een keer

Jy stuur jou eie identifiseerder vir die gebruiker. Jy kry adresse terug wat nooit verander nie, so die oproep gebeur by registrasie en nooit weer nie.

1. 01

   Skep die kliënt met jou eie id

   Stuur die gebruiker se bestaande id as `external_ref`. Unheld skep nie ’n identifiseerder wat jy dan moet stoor en afbeeld nie — die rekord word geïndekseer op die id wat jou databasis reeds gebruik.

2. 02

   Stoor die adresse wat jy terugkry

   Die antwoord dra daardie gebruiker se deposito-adresse, afgelei uit jou eie beursie. Hulle is permanent, so jy kan hulle vertoon, in ’n QR-kode sit, of die gebruiker laat stoor en van enige plek af stuur.

3. 03

   Krediteer die rekening wanneer die webhoek opdaag

   ’n Betaling na daardie adres word toegeskryf aan die kliënt aan wie dit behoort, en die kennisgewing dra jou eie `externalRef` terug na jou. Jou toepassing krediteer ’n gebruiker-id wat dit reeds ken, sonder om bedrae te pas of ’n ketting te lees.

Die werklike oproep

Versoek

curl -X POST https://api.unheld.io/api/v1/customers \
  -H "Authorization: Bearer $UNHELD_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "external_ref": "user_8412",
    "label": "Ada Lovelace",
    "supported_assets": ["ETH", "USDC"],
    "evm": true
  }'

Antwoord

{
  "id": "c7f1…",
  "external_ref": "user_8412",
  "label": "Ada Lovelace",
  "evm_address": "0x…",
  "supported_assets": ["ETH", "USDC"],
  "receive_method": "auto"
}

Vereis ’n API-sleutel met die `customers:write`-omvang; om hulle terug te lees verg `customers:read`. Adresse vir elke ketting waarop ’n gebruiker kan betaal is beskikbaar by `GET /api/v1/customers/:id/addresses`.

Hoe ’n betaling sy gebruiker vind

Fakture kan ook met `customerId` aan ’n kliënt gekoppel word, sodat ’n eenmalige heffing en ’n staande deposito-adres aan dieselfde gebruiker toegeskryf word, in jou paneelbord én in jou webhoeke.

Waar die geld werklik lê

Wat dit jou nié sê nie, is of jóú platform fondse vir jou gebruikers hou. Waarskynlik wel, as betalings op adresse beland wat jy beheer en jy die waarde aan jou gebruikers skuld. Dit is ’n vraag oor jou eie reëling en jurisdiksie, en nie een wat ons namens jou kan beantwoord nie — kry advies daaroor. Ons kan net ons kant stel: die geld gaan nooit deur Unheld nie.

Om hierop te bou

Elkeen hiervan is nou makliker om voor te ontwerp as om in produksie te ontdek.

• Elke gebruikersadres word uit een beursie afgelei — joune. Dit laat jou met een herstelfrase om te beskerm, nie een per gebruiker nie, en dit beteken die fondse word nie per gebruiker met sleutels geskei nie.
• ’n Permanente adres word doelbewus hergebruik, en dit is juis wat toeskrywing laat werk. Dit beteken ook dat ’n gebruiker se betalingsgeskiedenis aan jou op die ketting koppelbaar is deur enigiemand wat hul adres leer ken.
• ’n Gebruiker se adres is vas per kettingfamilie: dieselfde EVM-adres ontvang op elke EVM-netwerk wat jy geaktiveer het. Om ’n nuwe ketting te aktiveer vereis nie dat adresse heruitgereik word nie.
• Om ’n kliënt te skrap stop die dophou van sy adres; dit skuif nie — en kan nie skuif nie — wat reeds daarheen gestuur is. Geld wat ná skrapping opdaag bly joune, maar niks sal jou daarvan laat weet nie.

Vrae