495 / 691PAY·PROC

Bitcoin Payment Processor

Bitcoinový platební procesor

Software nebo služba propojuje objednávku s bitcoinovou platbou, sleduje její stav a předává výsledek pokladně. Způsob úschovy, potvrzení platby a následného vypořádání závisí na konkrétním řešení.

Bitcoin Payment Processor vytváří platební požadavky, přiřazuje přijaté platby k objednávkám a podporuje jejich evidenci. Může běžet ve vlastní správě nebo jako služba. Sám není pravidlem bitcoinového konsenzu a označení procesor neříká, kdo ovládá prostředky.

Obchod vytvoří objednávku a jeho server požádá procesor o fakturu s částkou a měnou. Uloží vazbu mezi interním číslem objednávky a identifikátorem faktury. Zákazník dostane platební stránku nebo QR kód a procesor sleduje přijetí. Bez této vazby nelze spolehlivě určit, kterou objednávku platba vyřizuje; samotný návrat do prohlížeče není důkaz zaplacení. [BTCPay Server — eCommerce integration]

BTCPay Server může odvozovat přijímací adresy z veřejných údajů existující peněženky bez jejího soukromého klíče. To se liší od horké peněženky uložené na serveru i od přístupu k prostředkům Lightning uzlu. Poskytovatel může prostředky držet do výplaty. Posuzujte skutečné držení klíčů, oprávnění a možnost výběru, nikoli pouze název produktu nebo slovo non-custodial. [BTCPay Server — General FAQ] [BitPay — Configuring settlements]

Běžná faktura BTCPay Server uzamkne kurz na omezený čas. Vypršení neznamená, že pozdější převod nemůže dorazit. Nedoplatek, přeplatek a opožděná platba mají odlišné stavy a vyžadují návazný postup. Uložte původní částku a použitý kurz; nově vystavený požadavek nemusí při změně ceny požadovat stejný počet satoshi. [BTCPay Server — Invoice lifecycle]

BTCPay Server rozlišuje Processing, čekající na nastavená potvrzení, a Settled; úspěšné Lightning platby přecházejí do Settled bez čekání na blok. Názvy stavů jiných poskytovatelů nelze mechanicky ztotožnit: BitPay výslovně varuje, že paid není zárukou platby. Obchod musí mít pravidlo vydání zboží pro konkrétní stav a platební metodu. Ruční změna stavu nevytváří síťové potvrzení. [BTCPay Server — Invoice lifecycle] [BitPay — Invoice webhooks]

BTCPay ověřuje webhook pomocí HMAC-SHA256 nad původními bajty těla a sdíleným tajemstvím. BitPay popisuje nepodepsané IPN: oznámení je podnět k dotazu na stav faktury přes API, nikoli samo důvěryhodný doklad. Oznámení mohou přijít opakovaně. Integrace proto musí znovu doručenou událost bezpečně rozpoznat a zabránit druhé expedici stejné objednávky; po výpadku je nutné srovnat uložené stavy s procesorem. [BTCPay Server — Webhook validation example] [BitPay — Invoice webhooks]

Potvrzení zákazníkovy platby se nemusí časově shodovat s výplatou od poskytovatele. BitPay umožňuje nastavit měnu vypořádání a bankovní účet nebo kryptoměnovou adresu; změna může vyžadovat schválení. Ověřte dostupné měny, limity, termíny, poplatky a kontrolu prostředků do výplaty. Přímý příjem do vlastní peněženky tento model poskytovatelské výplaty automaticky nepoužívá. [BitPay — Configuring settlements] [BTCPay Server — General FAQ]

Refundace vyžaduje další výplatu a ověření příjemce; nemění původní bitcoinovou transakci. Oddělte reklamaci objednávky, rozhodnutí o vracené částce a skutečné odeslání peněz. Uchovávejte vazby objednávka–faktura–platba, kurzy, poplatky a refundace. Export reportu pomáhá s evidencí, ale sám neřeší všechny místní účetní povinnosti ani spor o dodání zboží. Ani potvrzený převod sám neřeší právní konečnost obchodu: reklamace, případný chargeback a povinnosti ověřte podle platební cesty, smlouvy a jurisdikce. [BTCPay Server — Refunds] [BTCPay Server — Reporting] [BitPay — Merchant and shopper terms]

Vyzkoušejte úspěšnou, neúplnou, opožděnou i opakovaně oznámenou platbu a obnovu po výpadku. API klíči dejte jen potřebná oprávnění a omezte jej na příslušný obchod. Do metadat nepřenášejte zbytečné údaje zákazníka. Počítejte s hostingem, aktualizacemi, likviditou a podporou; bezplatný software neznamená nulové provozní náklady. Dostupnost služby, držení klíčů a správnost integrace jsou samostatné podmínky. [BTCPay Server — eCommerce integration] [BTCPay Server — Lightning operations]

Příklad · PAY·PROC

Stejné oznámení není další nákup

V modelové integraci má objednávka OBJ-101 uložený identifikátor faktury. Po ověření jejího vypořádání systém jednou vytvoří expedici. Když později přijde opakované oznámení stejné události, přiřadí je k již vyřízené objednávce a další expedici nevytvoří. Pouhé zobrazení stránky s poděkováním by tento přechod vyvolat nesmělo.

Pro nejúplnější obraz čtěte toto heslo společně s BTCPay Server, Bitcoin Point of Sale, Merchant Adoption, Lightning Network, Bitcoin. Opačným směrem na něj odkazují také Bitcoinové platby v Alze, Merchant Adoption, BTCPay Server, Bitcoin Point of Sale.

01Drží každý platební procesor moje bitcoiny?

Ne. Některá řešení jen vytvářejí požadavky a sledují příjem do vaší peněženky, jiná prostředky spravují do výplaty. I stejný software může používat odlišné modely peněženek. Rozhodující jsou klíče, oprávnění a skutečný tok prostředků, nikoli samotné označení procesor.

02Může obchod expedovat po návratu zákazníka z platební stránky?

Samotný návrat nestačí. Obchod musí ověřit odpovídající fakturu a její stav postupem daného procesoru. Oznámení se ověřují podle dokumentace a opakované doručení nesmí spustit další plnění. Vydání zboží se řídí zvolenými podmínkami potvrzení platby.

DOC · 001BTCPay Server — eCommerce integrationDokumentace ↗DOC · 002BTCPay Server — General FAQDokumentace ↗DOC · 003BTCPay Server — Invoice lifecycleDokumentace ↗DOC · 004BTCPay Server — Webhook validation exampleDokumentace ↗DOC · 005BitPay — Invoice webhooksDokumentace ↗DOC · 006BitPay — Configuring settlementsDokumentace ↗DOC · 007BTCPay Server — RefundsDokumentace ↗DOC · 008BTCPay Server — ReportingDokumentace ↗DOC · 009BTCPay Server — Lightning operationsDokumentace ↗DOC · 010BitPay — Merchant and shopper termsPrimární zdroj ↗
Primární zdroje · Nejde o investiční doporučení