exact i upto. Rozwiązują one różne problemy związane z rozliczeniami.
exact
exact oznacza, że cena za tę prośbę może być ustalona przed wejściem do docelowego API. Kwota podpisana przez klienta jest ostateczną kwotą do pobrania.
Odpowiednie dla:
- Generowania obrazów po stałej cenie;
- Tworzenia zadań wideo po stałej cenie;
- Stałej ceny za API wyszukiwania lub narzędzi;
- Płatności za zamówienia.
exact używa USDC EIP-3009 TransferWithAuthorization:
/verify weryfikuje podpis i kwotę, a w etapie /settle przesyła tę autoryzację na łańcuch.
upto
upto oznacza, że klient autoryzuje maksymalny limit, a Ace Data Cloud rozlicza się na podstawie rzeczywistego zużycia po zakończeniu żądania, a rzeczywista kwota do pobrania nie może przekroczyć limitu.
Odpowiednie dla:
- Uzupełniania czatu: ostateczna cena zależy od tokenów prompt i tokenów completion;
- Odpowiedzi strumieniowej: rzeczywista długość wyjścia jest znana dopiero po zakończeniu;
- Przyszłych API z pomiarem po wykonaniu.
upto używa Permit2 PermitWitnessTransferFrom. Podpisana przez klienta kwota nie jest stałym przelewem, lecz autoryzacją z limitem z świadkiem:
permitted.amount to limit, który niekoniecznie jest ostateczną kwotą do pobrania. Gateway w etapie /record przekształci rzeczywiste zużycie na amount i przekaże je do Facilitatora. Facilitator może rozliczyć tylko amount <= permitted.amount.
Wynik działania programu Base upto:
- Wartość autoryzacji zwrócona w 402 to
95215atomic USDC, klient podpisuje według tego limitu. - Po rzeczywistej odpowiedzi modelu rozliczana jest tylko kwota
3atomic USDC, transakcja na łańcuchu jest dostępna w BaseScan. - Ten wynik ilustruje kluczową różnicę
upto: podpisana kwota to limit, a rozliczenie na łańcuchu może być mniejsze od limitu. - Jeśli rzeczywiste zużycie przekroczy limit, Facilitator powinien odmówić rozliczenia, a klient musi ponownie autoryzować według wyższego limitu.
upto jest obecnie dostępne tylko na Base. SKALE oferuje tylko exact, jeśli potrzebujesz pomiaru po wykonaniu, użyj Base.
Dlaczego potrzebne jest zatwierdzenie Permit2
upto ostatecznie jest realizowane przez proxy x402 poprzez Permit2 z portfela płatniczego. Przed pierwszym użyciem portfel płatniczy musi raz zatwierdzić Permit2 dla ERC-20.
Python CLI:
upto, ponieważ nonce, deadline, świadek i limit kwoty są różne.
Rozliczenie zerowej kwoty
upto obsługuje sytuacje, w których rzeczywista kwota wynosi 0. Na przykład, jeśli docelowe API nie wygenerowało skutecznego zużycia, Gateway może przekazać amount = "0". Facilitator zwróci sukces, ale nie wyśle transakcji na łańcuch.
To może zapobiec problemowi “żądanie nie powiodło się, ale nadal pobrano opłatę na łańcuchu”.
Rekomendacje dotyczące wyboru
Jeśli nie jesteś pewien, który wybrać, najpierw użyj domyślnego zachowania SDK; SDK wybierze wymagania płatności zgodne z siecią zwróconą przez serwer.
Lista kontrolna Base upto
Podczas integracji lub rozwiązywania problemów, upewnij się, że poniższe parametry pochodzą z tej samej odpowiedzi 402 i są zgodne podczas podpisywania przez klienta:
Typowe błędy i sposoby ich rozwiązania:

