PSP Pembayaran Silang Batas Berkembang di Era Multi-Lintasan

icon MarsBit
Bagikan
Share IconShare IconShare IconShare IconShare IconShare IconCopy
AI summary iconRingkasan

expand icon
Penyedia layanan pembayaran lintas batas sedang membentuk ulang peran mereka di tengah perubahan tren industri. Sistem modern kini melibatkan beberapa jalur, termasuk aplikasi C-end, pemeriksaan penipuan, bank penitipan, dan akuntansi internal. PSP tradisional kesulitan dengan pembayaran real-time dan penyelesaian berbasis stablecoin. Stablecoin menjadi lapisan kunci untuk transaksi yang lebih cepat. Fragmentasi di ekosistem mempersulit pelacakan dan rekonsiliasi dana. Evolusi ini mencerminkan berita industri kripto yang lebih luas seiring infrastruktur beradaptasi dengan permintaan baru.

Penulis: Awang, Web3 Xiao Lu

Pembayaran digital sudah memasuki arus utama, tetapi penyelesaian belum.

Ini adalah penilaian dari Dan Mottice, mantan eksekutif Visa dan pendiri Beam. Transaksi Visa dapat diotorisasi di mana pun merchant di seluruh dunia, tetapi penyelesaian di baliknya masih berjalan melalui SWIFT—menggabungkan transaksi dalam batch, mentransfer dana melalui transfer kawat lintas batas, melewati regulasi lokal, hari libur, dan beberapa bank perantara, lalu merchant harus menunggu pembayaran masuk. Ini bukan masalah Visa, melainkan utang struktural seluruh industri. Dan PSP adalah tempat di mana utang ini paling terkonsentrasi.

Artikel ini berfokus pada penyedia layanan pembayaran (PSP), yang telah berkembang dari sekadar alat penerima pembayaran menjadi lapisan infrastruktur inti yang mengelola arus dana, penyelesaian, dan pembukuan. Mereka awalnya dirancang untuk era yang lebih sederhana—sistem satu jalur, proses transaksi linier, dan infrastruktur yang sangat terintegrasi.

Dalam lingkungan pembayaran modern, sebuah "pembayaran" bukan lagi satu transaksi tunggal, melainkan serangkaian perubahan status yang melibatkan berbagai pihak dan jalur pembayaran. Saat ini, sebuah pembayaran dapat melibatkan: aplikasi konsumen, PSP, penyedia layanan anti-penipuan/verifikasi identitas, bank penitipan, satu atau lebih jalur pembayaran, serta sistem akuntansi internal perusahaan.

Perusahaan harus mendukung sekaligus kartu bank, ACH, transfer bank, RTP, FedNow, serta semakin banyak penyelesaian berbasis stablecoin. Setiap jalur memiliki waktu penyelesaian, pola kegagalan, format data, dan persyaratan operasional yang berbeda.

Artikel ini mengompilasi panduan dari Modern Treasury yang akan membahas bagaimana PSP berkembang, arsitektur dasarnya perlu beradaptasi seperti apa untuk sistem pembayaran modern, serta strategi apa yang harus diambil oleh tim yang sedang membangun produk pembayaran saat memilih PSP berikutnya.

Penilaian inti

01|Pembayaran digital telah memasuki arus utama, tetapi penyelesaian belum. Visa memungkinkan Anda menyelesaikan otorisasi di mana pun merchant di seluruh dunia, tetapi penyelesaian di baliknya masih berjalan di SWIFT. Antarmuka telah diselesaikan, tetapi lapisan dasarnya belum.

02|PSP melakukan pembayaran, tetapi tidak menjelaskan aliran dana. Stripe memberi tahu Anda apa yang terjadi di bagiannya, tetapi tidak dapat memberi tahu Anda status sebenarnya dari uang tersebut sekarang. Lapisan eksekusi dan lapisan pencatatan adalah dua hal yang berbeda.

03| Setiap jalur pembayaran adalah sistem operasi independen, bukan varian dari model yang sama. ACH dapat dibatalkan, RTP tidak bisa; jaringan kartu dapat diperselisihkan, stablecoin memiliki konfirmasi akhir di blockchain. Lapisan abstraksi PSP menyamarkan perbedaan-perbedaan ini, tetapi hanya sampai masalah muncul.

04| Pembayaran real-time menghilangkan buffer, kontrol harus dipindahkan ke depan. Logika pengendalian risiko, persetujuan, dan rekonsiliasi PSP tradisional semuanya mengasumsikan "jika terjadi kesalahan, masih ada waktu untuk memperbaiki". RTP dan FedNow membuat asumsi ini tidak lagi berlaku. Keputusan harus diambil sebelum dana bergerak, bukan setelahnya.

05|Stablecoin adalah jalur penyelesaian, bukan metode pembayaran baru. Ia tidak menyelesaikan masalah antarmuka pembayaran, melainkan menangani keterlambatan antara "pencatatan selesai" hingga "pembayaran benar-benar diterima". Jalur penerapan paling praktis adalah struktur sandwich: fiat masuk, beredar di blockchain, fiat keluar—pengguna di kedua ujung tidak perlu memahami stablecoin.

06| Dana dalam perjalanan dapat menghasilkan keuntungan, yang hampir tidak ada dalam sistem tradisional. Dalam pembayaran lintas batas, dana terikat selama 24 hingga 72 jam sebelum penyelesaian, tanpa menghasilkan keuntungan dan membebati modal operasional. Stabilcoin pertama kali memungkinkan 'dana yang beredar' juga menghasilkan nilai.

07| Kegagalan terbesar dalam operasional pembayaran adalah ketidakmampuan untuk menjawab pertanyaan sederhana: Uang ini pergi ke mana? Rekonsiliasi, penanganan anomali, manajemen likuiditas—masalah-masalah ini tidak muncul saat pembayaran dimulai, tetapi muncul setelahnya. Tanpa lapisan koordinasi terpadu, setiap penyedia layanan hanya bisa menceritakan bagian ceritanya sendiri.

08| Risiko strategis sejati bukanlah apakah Anda menggunakan stablecoin atau tidak. Melainkan pesaing Anda telah merekonstruksi biaya penyelesaian dan efisiensi dana mereka dengan stablecoin, sementara Anda masih menunggu momen masuk yang sempurna.

I. Perkembangan sejarah PSP

Real-time payment

Dalam dua dekade terakhir, peran PSP telah mengalami perubahan mendasar.

Pada awal e-commerce, PSP berfungsi terutama sebagai gateway pembayaran. Tanggung jawabnya sederhana dan jelas: menghubungkan pedagang ke jaringan kartu dan bank akseptor, sehingga transaksi dapat diotorisasi dan diselesaikan.

Sistem PSP ini dirancang untuk dunia yang sangat spesifik. Pembayaran didominasi oleh kartu, mengalir melalui satu akun pedagang, dan mengikuti siklus hidup linier dari otorisasi hingga penyelesaian. PSP dioptimalkan untuk menangani transaksi secara efisien dalam model ini.

Pada dekade 2010-an, marketplace, platform SaaS, dan produk fintech mulai mengintegrasikan pembayaran langsung ke dalam produk mereka. Platform memerlukan proses pendaftaran pengguna, pembagian pembayaran di antara pihak-pihak yang berbeda, dan pengelolaan pencairan dana. PSP kemudian berkembang dengan memperkenalkan infrastruktur pendaftaran merchant, pencairan dana, dan alat pencegahan penipuan.

Namun, meskipun kemampuan PSP terus berkembang, arsitektur dasarnya masih berakar pada model yang dirancang untuk proses pembayaran linier—utamanya dioptimalkan untuk pemrosesan transaksi, bukan untuk mengoordinasikan perpindahan dana kompleks multi-langkah yang melintasi penyedia layanan dan jalur yang berbeda.

Pada awal dekade 2020, perusahaan mulai beroperasi melalui berbagai jalur, wilayah, dan skenario. PSP tradisional terus menggabungkan banyak komponen, memungkinkan perusahaan berinteraksi dengan satu platform tunggal. Namun, seiring proses pembayaran menjadi lebih kompleks, satu proses pembayaran mungkin mencakup beberapa langkah: verifikasi identitas, pemindaian risiko, keputusan dana, eksekusi jalur, dan pelacakan internal.

Perubahan ini membuat peran PSP berubah dari "penghubung" menjadi "koordinator", tetapi arsitekturnya tidak berkembang dengan kecepatan yang sama.

The result is: PSP still handles fund transfers, but operates within a more complex, full transaction payment lifecycle environment.

Dua: Tumpukan teknologi pembayaran PSP modern

Untuk memahami keterbatasan PSP, Anda harus terlebih dahulu memahami lingkungan pembayaran yang lebih luas di mana ia beroperasi.

Real-time payment

2.1 Teknologi PSP

Lingkungan pembayaran modern bukanlah satu platform atau penyedia layanan tunggal, melainkan serangkaian komponen infrastruktur berlapis yang bersama-sama mendukung pergerakan, penyelesaian, dan pencatatan dana.

Lapisan aplikasi: platform e-commerce yang memulai pembayaran, Marketplace, aplikasi fintech, produk SaaS dengan pembayaran tersemat.

Lapisan PSP: Bertanggung jawab untuk mengeksekusi instruksi pembayaran, seperti mengarahkan transaksi ke jaringan kartu, memulai transfer bank, atau menghubungkan ke jalur pembayaran. Dalam sebagian besar kasus, kompleksitas dasar ini diabstraksikan di balik antarmuka PSP, sehingga pengguna berinteraksi dengan satu sistem tunggal, bukan langsung menghadapi berbagai penyedia layanan di baliknya.

Lapisan kepatuhan: Proses pembayaran modern juga bergantung pada penyedia verifikasi identitas, alat deteksi penipuan, dan infrastruktur kepatuhan, yang menentukan apakah pembayaran boleh dilanjutkan.

Tingkat perbankan: Bank penitipan menyimpan dana, menyediakan akun yang diatur, dan mendukung akses ke jaringan pembayaran seperti ACH, wire transfer, RTP, dan FedNow.

Lapisan rekonsiliasi internal: Sistem yang digunakan perusahaan untuk melacak saldo, menunjukkan status transaksi, dan mempertahankan catatan konsisten tentang aktivitas keuangan.

Setiap lapisan di atas memainkan peran dalam pergerakan dana, tetapi tidak ada satupun yang memberikan gambaran lengkap tentang apa yang sebenarnya terjadi setelah pembayaran dimulai. Inilah mengapa lapisan rekonsiliasi internal menjadi tak tergantikan.

2.2 Sinkron dan Asinkron

PSP tradisional memiliki cacat desain mendasar: ia hanya bertanggung jawab mengirimkan uang, bukan memantau apa yang terjadi setelah uang dikirim.

Masalahnya adalah, "setelah dikirim" justru merupakan bagian paling kompleks dalam pembayaran.

Logika antarmuka API PSP bersifat sinkron—Anda mengirimkan satu perintah, dan ia mengembalikan satu hasil. Namun, aliran dana yang sebenarnya bersifat asinkron: penyelesaian dilakukan setelahnya, kegagalan muncul dengan keterlambatan, dan pengembalian dana serta koreksi dapat kapan saja diproses kembali. Ketidaksesuaian ini menciptakan lubang informasi yang terus-menerus ada.

Manifestasi spesifik dari black hole adalah fragmentasi status:

Real-time payment

Tidak ada satu pun node yang dapat memberitahu Anda status sebenarnya dari uang ini saat ini.

Sebagai contoh penarikan dana oleh penjual di platform pasar, seluruh proses merupakan rantai panjang: verifikasi kualifikasi → kepatuhan dan manajemen risiko → konfirmasi dana → pengiriman instruksi → eksekusi jalur → pengembalian konfirmasi → penyelesaian pasca-transaksi → pembaruan buku besar. PSP hanya mencakup beberapa tahap tengah, sementara keputusan awal dan rekonsiliasi akhir berada di luar tanggung jawabnya. Jika pembayaran ini gagal atau dikembalikan, tidak ada sistem yang dapat memberikan jawaban lengkap.

Inilah tujuan keberadaan lapisan reconciliasi internal: ia tidak menggantikan PSP dalam melakukan pembayaran, tetapi membangun lapisan pengamatan terpadu di atas seluruh rantai—menerjemahkan secara terus-menerus peristiwa asinkron dari berbagai penyedia layanan, waktu yang berbeda, dan format yang berbeda menjadi satu status tunggal yang dapat dipercaya oleh perusahaan. Tidak peduli seberapa banyak tahapan perantara yang dilalui uang, selalu ada satu tempat yang dapat menjawab pertanyaan paling mendasar: uang ini, sekarang berada di mana?

Tiga: Keterbatasan pembayaran PSP tradisional

Lapisan abstraksi PSP tradisional dibangun di sekitar pembayaran kartu bank—otorisasi, penangkapan, penyelesaian, dengan siklus hidup yang dapat diprediksi. Meskipun ada pengecualian (seperti perselisihan dan penolakan), struktur keseluruhan dapat diprediksi dan dipahami dengan baik. Model ini membentuk cara desain PSP.

Dengan munculnya metode pembayaran baru, PSP memperluas cakupan dukungan ke lebih banyak jalur, tetapi perilaku jalur-jalur ini berbeda dari kartu bank dan tidak sesuai dengan asumsi yang sama:

  • Transfer ACH: Telah diperkenalkan penundaan, serta kemungkinan pembayaran dapat dibatalkan beberapa hari setelah dimulai.
  • Wire transfer: Faster settlement, but typically requires manual processes and higher costs.
  • Jaringan pembayaran real-time seperti RTP dan FedNow: memungkinkan perpindahan dana secara instan, tetapi transaksi biasanya tidak dapat dibatalkan setelah selesai.
  • Transfer stablecoin: berjalan di infrastruktur yang sama sekali berbeda, dengan mekanisme jaminan dan pertimbangan operasional yang berbeda.

Sebagai contoh, perusahaan Amerika mentransfer dana ke pemasok Filipina:

  • Gunakan ACH, pencairan dalam T+2, tetapi bank Filipina tidak menerima ACH secara langsung, perlu ditransfer melalui jalur lokal terlebih dahulu, sehingga pencairan sebenarnya bisa sampai T+4, dan selama periode ini, transfer dapat dibatalkan kapan saja karena ketidaksesuaian informasi akun.
  • Gunakan transfer bank, lebih cepat, tetapi pastikan untuk mengirim sebelum batas waktu transfer pukul 15.00, jika jatuh pada hari libur, akan ditunda. Biaya SWIFT $25 hingga $45, dan bank penerima mungkin mengenakan biaya tambahan dari bank perantara, sehingga jumlah yang diterima tidak sama dengan jumlah yang dikirim.
  • Gunakan sandwich stablecoin, USDC dikirim dari akun AS, dikonfirmasi dalam beberapa detik di blockchain, mitra Filipina menerimanya, kemudian menukarnya menjadi peso dan menyetorkannya ke akun lokal, seluruh proses tidak lebih dari satu jam, dengan biaya di bawah 1% dari jumlah transfer.

Tiga jalur, uang yang sama, waktu penyelesaian berbeda 96 jam, biaya berbeda puluhan dolar, dan tingkat pelacakan sama sekali berbeda. Ini bukan perbedaan pengalaman produk, melainkan perbedaan antara tiga sistem operasi yang berbeda. Lapisan abstraksi PSP tidak dapat menyamarkan hal-hal ini; ia hanya mendorong perbedaan tersebut ke atas kepada pengembang dan tim operasional untuk mengatasinya.

Ini bukan varian dari model pembayaran yang sama, tetapi model operasi yang sama sekali berbeda.

Cara tradisional PSP menanggapi hal ini adalah dengan menyediakan API dan definisi status yang berbeda untuk setiap jalur—tidak ada penyatuan nyata terhadap perbedaan, hanya mendorong perbedaan tersebut ke atas kepada pengembang. Tim teknik mulai menulis logika khusus untuk setiap jalur, tim operasional mulai menangani secara manual berbagai mode kegagalan, dan tim keuangan mulai melakukan rekonsiliasi untuk transaksi sejenis yang melewati jalur yang sama sekali berbeda.

Inilah kebocoran abstraksi: kompleksitas jalur yang seharusnya disembunyikan mulai merembes ke lapisan aplikasi.

Dengan semakin banyak jalur yang ditambahkan, lingkungan pembayaran berubah menjadi serangkaian integrasi yang longgar, bukan lapisan abstraksi yang terpadu. Di jalur yang lebih lambat, keterlambatan memberikan jendela waktu untuk mendeteksi masalah. Di jalur real-time, jendela ini hilang—pembayaran diselesaikan dalam hitungan detik, kesalahan tidak dapat dibatalkan dengan mudah, dan keputusan harus diambil sebelum dana bergerak, bukan setelahnya.

Empat: Pembayaran real-time memaksa PSP untuk memajukan kendali

Perpindahan ke jaringan pembayaran real-time bukan hanya mempercepat kecepatan aliran dana—tetapi secara mendasar mengubah persyaratan desain infrastruktur pembayaran.

Di era ACH dan transfer bank, waktu adalah penyangga.

ACH mungkin memerlukan beberapa hari untuk penyelesaian, transaksi kartu bank dapat memicu disput setelah otorisasi, dan transfer bank sering melibatkan langkah pemeriksaan manual. Penundaan ini, meskipun menyebabkan penurunan efisiensi, juga memberikan kesempatan untuk mendeteksi kesalahan, mengintervensi aktivitas mencurigakan, dan menyelesaikan rekonsiliasi sebelum penyelesaian final.

Model PSP tradisional dibangun di sekitar buffer ini.

Real-time payment

Namun, jaringan pembayaran real-time seperti RTP dan FedNow benar-benar menghancurkan asumsi ini. Dana mengalir langsung antar akun dalam hitungan detik, dan pembayaran biasanya tidak dapat dibatalkan setelah selesai.

  • Deteksi penipuan harus diselesaikan lebih awal
  • Pemeriksaan kepatuhan harus dilakukan secara real-time
  • Keputusan dana harus diselesaikan secara akurat pada saat pembayaran dirilis
  • Peluang untuk memperbaiki kesalahan setelah kejadian tidak lagi ada

Platform yang menyediakan pembayaran instan tidak dapat mengandalkan alur kerja yang dirancang untuk penyelesaian tertunda. Sistem internal perusahaan yang mengelola dana pembayaran di banyak akun tidak dapat menentukan likuiditas secara instan saat dieksekusi. Tim layanan pelanggan tidak dapat menjamin kemungkinan pembatalan, ketika infrastruktur dasarnya sama sekali tidak memungkinkannya.

Hasilnya adalah pergeseran tanggung jawab: PSP harus berkembang untuk mendukung sistem internal yang menentukan kapan pembayaran harus dilakukan. Dengan kata lain, kendali harus dipindahkan ke depan.

Infrastruktur pembayaran harus dirancang sedemikian rupa sehingga persetujuan, logika dana, pemeriksaan risiko, dan verifikasi status harus diselesaikan sebelum aliran dana terjadi, bukan setelahnya. Ini memerlukan pandangan yang lebih terkoordinasi mengenai saldo, status transaksi, dan kondisi lintas penyedia layanan dibandingkan yang dapat disediakan oleh arsitektur PSP tradisional.

Real-time tracking bukanlah keadaan akhir, hanya sebuah titik balik. Setelah stablecoin masuk, masalah akan naik ke tingkat yang lebih tinggi.

V. Stablecoin: Jalur Baru, Bukan Metode Pembayaran Baru

Kesalahpahaman paling umum tentang stablecoin adalah menganggapnya sebagai produk pembayaran baru. Bukan. Stablecoin adalah jalur penyelesaian baru yang menyelesaikan keterlambatan antara "pencatatan selesai" dan "penerimaan aktual".

Berbeda dengan kartu, ACH, dan transfer bank, transaksi stablecoin berjalan di jaringan blockchain:

  • Settlement berlangsung terus-menerus, bukan secara batch
  • Konfirmasi akhir hampir instan (tergantung jaringan)
  • Beroperasi 7×24 jam, tanpa batas waktu penutupan bank dan libur hari libur
  • Tidak bergantung pada sistem pembayaran domestik tertentu
  • Primitif untuk melacak saldo, kepemilikan, dan riwayat transaksi sama sekali berbeda

Arsitektur PSP tradisional dibangun di sekitar integrasi dengan bank dan jaringan pembayaran, sementara stablecoin memperkenalkan jaringan yang tidak bergantung pada perantara tersebut. Asal, penyelesaian, dan pencatatan terjadi di luar desain aslinya. Sebuah perusahaan mungkin perlu secara bersamaan mengoordinasikan jalur bank, jaringan real-time, dan penyelesaian on-chain, di mana masing-masing jenis memiliki asumsi berbeda mengenai finalitas, urutan waktu, dan kontrol—perbedaan ini tidak dapat disatukan melalui satu API tunggal, sehingga posisi PSP sebagai lapisan abstraksi tunggal semakin sulit dipertahankan.

Seperti sistem pembayaran real-time yang menantang asumsi tentang urutan dan reversibilitas, stablecoin menantang asumsi tentang lokasi dan cara pembayaran terjadi.

Dalam proses ini, mereka memperkenalkan tingkat kompleksitas baru.

Stablecoin sandwich adalah jalur paling praktis saat ini: fiat masuk → beredar di blockchain → fiat keluar.

Pelanggan dan pemasok di kedua sisi perdagangan tidak perlu memahami stablecoin; stablecoin hanyalah saluran perantara—secara khusus dirancang untuk menyelesaikan jalur pembayaran lintas batas yang lambat, mahal, dan tidak stabil. Aplikasi paling berharga berfokus pada "jalur sulit," yaitu skenario lintas batas di mana cara tradisional lambat, mahal, atau sama sekali tidak dapat diakses.

Perusahaan tidak akan dan seharusnya tidak All-in pada stablecoin; jalur realistis adalah memilih satu atau dua kasus penggunaan spesifik untuk penggantian terbatas, membangun pemahaman, lalu memperluasnya.

Stablecoin juga membawa dimensi tambahan: pendapatan dana dalam perjalanan, yang hampir tidak ada dalam sistem tradisional. Dalam proses pembayaran tradisional, dana membutuhkan waktu 24 hingga 72 jam dari pengiriman hingga penerimaan, tanpa menghasilkan pendapatan sekaligus mengikat modal operasional. Stablecoin di blockchain dapat menghasilkan pendapatan selama perjalanan—bukan hanya optimasi kecil terhadap biaya pembayaran, tetapi rekonstruksi keseluruhan logika efisiensi dana.

Enam: Ekosistem Saat Ini: Sepuluh Lapisan Pembagian Tugas dan Lapisan yang Hilang

Seiring dengan infrastruktur pembayaran yang melintasi lebih banyak jalur, lebih banyak penyedia layanan, dan lebih banyak jenis infrastruktur, definisi peran PSP menjadi semakin sulit.

Tanggung jawab pemindahan dana yang sebelumnya terikat dalam satu PSP kini menjadi serangkaian tanggung jawab yang tersebar di berbagai lapisan teknologi.

PSP tidak lagi hanya memindahkan dana, tetapi juga menjelaskan aliran dana.

Perubahan ini mencerminkan perubahan yang lebih mendalam: eksekusi saja kini tidak lagi cukup. PSP sekarang harus mendukung sistem internal perusahaan agar dapat merepresentasikan, mencatat, dan melakukan rekonsiliasi bagaimana dana mengalir di berbagai lingkungan yang berbeda.

Real-time payment

① Platform lapisan produk: Menanamkan pembayaran ke dalam perangkat lunak

Platform perangkat lunak vertikal seperti Shopify, Square, Toast, Mindbody, ServiceTitan, dan Housecall Pro secara langsung mengintegrasikan pembayaran ke dalam produk mereka.

Dalam skenario-skenario ini, pembayaran diintegrasikan ke dalam pengalaman aplikasi, bukan ditangani sebagai sistem pembayaran terpisah. Platform-platform ini biasanya bergantung pada PSP dasar, mitra perbankan, dan penyedia infrastruktur untuk menambahkan lapisan abstraksi tambahan antara aplikasi dan arus dana.

② Lapisan Eksekusi: Pemindahan Dana Antar Orbit

Inti dari tumpukan teknis adalah penyedia layanan yang bertanggung jawab atas eksekusi pembayaran. Termasuk PSP tradisional seperti Stripe, Adyen, Checkout.com, Worldpay, PayPal, Nuvei, dLocal, yang perannya menghubungkan perusahaan ke jalur pembayaran dan memfasilitasi perpindahan dana.

Mereka tetap menjadi komponen kunci dalam tumpukan teknologi pembayaran, tetapi beroperasi terutama di lapisan eksekusi—memulai pembayaran, melaporkan status, dan mengekspos API, tetapi tidak menyediakan model lengkap tentang bagaimana dana mengalir di antara penyedia layanan dan sistem internal.

Anda bertanya kepada Stripe "Uang ini sekarang berada di mana?", dan Stripe hanya bisa memberi tahu Anda apa yang terjadi pada bagian miliknya. Stripe hanyalah salah satu simpul; transaksi ini mungkin mencakup lima atau enam tahap lainnya, seperti PSP, bank, jalur, dan buku besar internal, tetapi yang selalu dilihatnya hanyalah bagian lokal, bukan keseluruhan.

③ Lapisan penyusunan dan routing: Menghubungkan penyedia eksekusi

Seiring dengan adopsi perusahaan terhadap beberapa PSP dan metode pembayaran, muncullah platform orkestrasi yang bertanggung jawab mengelola routing lintas penyedia layanan. Perusahaan seperti Primer, Gr4vy, Spreedly, Paydock, dan CellPoint Digital memungkinkan perusahaan untuk mengarahkan transaksi berdasarkan wilayah, biaya, atau kinerja. Sistem-sistem ini meningkatkan fleksibilitas di tingkat eksekusi, tetapi tidak menyediakan model terpadu untuk perilaku setelah inisiasi pembayaran.

④ Lapisan manajemen risiko dan kepatuhan: Menentukan apakah dana seharusnya dipindahkan

Sejumlah penyedia layanan independen bertanggung jawab untuk menilai apakah pembayaran boleh dilanjutkan. Sistem verifikasi identitas, deteksi penipuan, dan kepatuhan dari penyedia seperti Persona, Sardine, Alloy, Unit21, Sift, dan Sumsub mengevaluasi pengguna dan transaksi sebelum eksekusi. Dalam lingkungan real-time, keputusan ini harus diselesaikan sebelum dana dipindahkan, sehingga logika kontrol kritis dipindahkan keluar dari PSP.

⑤ Lapisan infrastruktur perbankan: Menyimpan dana dan mendukung akses

Bank penitipan seperti Cross River Bank, Lead Bank, Column, dan Sutton Bank menyediakan akun yang diatur dan akses ke jaringan pembayaran. Mereka memegang dana pelanggan, mengelola likuiditas, dan bertindak sebagai gerbang untuk mengakses saluran seperti ACH, wire transfer, RTP, dan FedNow. Lapisan ini sangat penting untuk akses ke sistem keuangan, tetapi beroperasi secara independen dari logika aplikasi dan API PSP.

⑥ Lapisan penerbitan kartu: Perluas fungsi pembayaran

Platform penerbit kartu seperti Marqeta, Lithic, dan Rain memungkinkan perusahaan untuk menerbitkan kartu debit dan kartu kredit sebagai bagian dari produk mereka, mendukung skenario penggunaan seperti manajemen biaya, kartu perusahaan, dan konsumsi pasar. Platform penerbit terhubung ke bank dan jaringan kartu, tetapi beroperasi sebagai lapisan independen dalam teknologi stack, memperkenalkan alur kerja, mekanisme kontrol, dan status tambahan yang perlu disinkronkan dengan bagian lain dari stack pembayaran.

⑦ Lapisan Pembayaran: Jaringan Eksekusi Dasar

Payment rails adalah jaringan yang memindahkan dana di antara lembaga keuangan. Rail tradisional mencakup ACH, transfer kawat, dan jaringan kartu, sementara jaringan baru seperti RTP dan FedNow mendukung penyelesaian real-time. Setiap rail memiliki asumsi yang berbeda dalam hal waktu, kepastian, dan reversibilitas, menciptakan ketidaksesuaian yang harus dihadapi atau dihindari oleh PSP (bukan sepenuhnya diabstraksikan).

⑧ Lapisan jaringan stablecoin: Diperluas di luar infrastruktur perbankan

Jaringan stablecoin seperti Ethereum, Solana, Polygon, dan Base memperkenalkan bentuk baru infrastruktur pembayaran yang beroperasi di luar sistem perbankan tradisional. Jaringan-jaringan ini melakukan transfer dolar digital di infrastruktur global dengan model penyelesaian dan mekanisme jaminan yang berbeda. Mereka memperluas cakupan sistem pembayaran di luar jalur berbasis perbankan, menambahkan lapisan kompleksitas tambahan yang harus diintegrasikan ke dalam alur kerja yang ada.

⑨ Lapisan Bank sebagai Layanan: Menghubungkan aplikasi dengan bank

Platform bank sebagai layanan (BaaS) seperti Unit, Galileo, dan Treasury Prime menyediakan infrastruktur untuk menghubungkan aplikasi fintech dengan bank yang diatur. Mereka memungkinkan perusahaan menyediakan akun, kartu, dan kemampuan pembayaran tanpa harus menjadi bank. Lapisan ini menyederhanakan akses ke infrastruktur perbankan, tetapi menambahkan pihak perantara tambahan di antara aplikasi, PSP, dan arus dana dasar.

⑩ Lapisan yang hilang: PSP terpadu yang mencakup seluruh siklus hidup arus dana

Melihat kesembilan lapisan di atas, polanya konsisten: setiap penyedia layanan bertanggung jawab atas fungsi tertentu, dan tidak ada satu pun yang dapat menyediakan gambaran lengkap tentang arus dana—termasuk pemahaman, pengendalian, dan rekonsiliasinya.

Eksekusi ditangani oleh satu penyedia layanan, keputusan risiko ditangani oleh yang lain, dana disimpan di bank, dan proses pembayaran dapat melibatkan jaringan kartu, jalur real-time, dan sistem on-chain. Setiap sistem mengekspos data, timeline, dan definisi status yang berbeda.

Dalam lingkungan yang terfragmentasi, masalah ini tidak muncul pada tahap awal—ia muncul setelah kejadian: ketika sistem mengalami perbedaan, dana tertunda atau dikembalikan, dan tim membutuhkan jawaban. Inilah titik di mana sistem pembayaran mulai runtuh.

Tujuh, di mana operasi pembayaran gagal

Jumat pukul 14:55, tim keuangan mengirimkan transfer bank senilai $50.000 kepada pemasok. Pukul 15:00, batas waktu transfer bank. Sistem menampilkan «Telah Diajukan», tetapi email konfirmasi belum masuk.

Pukul 16.00, pemasok mengirim pesan menanyakan status pembayaran. Keuangan memeriksa backend PSP, yang menunjukkan "sedang diproses". Kemudian memeriksa rekening bank, yang menunjukkan "menunggu penyelesaian". Dua sistem, satu pembayaran, dua status berbeda, tanpa satu pun yang bisa memberi tahu di mana node pembayaran saat ini.

Jam 5 sore Jumat, layanan pelanggan bank selesai bekerja. Pemasok menunggu penjadwalan pembayaran untuk pengiriman akhir pekan. Tim keuangan tidak tahu apa yang harus dikatakan kepada pemasok, atau apakah uangnya akan otomatis masuk Senin pagi, atau sudah dikembalikan dan perlu diproses ulang.

Ini bukan kasus ekstrem, melainkan skenario yang dialami tim operasional pembayaran setiap minggu. Ini tidak akan muncul di manual produk PSP, tetapi akan muncul di catatan kerja setiap tim pembayaran lintas batas.

Masalah paling sulit dalam pembayaran sering kali bukan pada tahap awal, tetapi setelahnya—ketika tim perlu menjelaskan apa sebenarnya yang terjadi.

Peta pasar pada bab sebelumnya mengungkapkan luasnya ekosistem pembayaran. Sebuah pembayaran yang tampaknya tunggal sering kali telah melewati beberapa penyedia layanan dalam tumpukan teknis sebelum penyelesaian terjadi. Setiap pihak mungkin memiliki representasi yang berbeda terhadap pergerakan dana yang sama, urutan waktu yang berbeda, status yang berbeda, dokumen yang tiba sesuai jadwal berbeda, dan anomali yang dilaporkan melalui saluran berbeda.

Ini adalah saat operasi pembayaran menjadi sulit.

Reconciliation: Multiple versions of the same event

Tim keuangan perlu mencocokkan buku internal dengan rekening bank, laporan penyelesaian, dan data penyedia layanan. Jika satu penyedia layanan menunjukkan pembayaran telah selesai, sementara yang lain menunjukkan masih dalam proses, perusahaan memerlukan model untuk menyelesaikan perbedaan tersebut. Jika retur tiba setelah saldo internal telah diperbarui, buku besar perlu melakukan pembatalan atau penyesuaian yang sesuai.

Penanganan pengecualian: gangguan tanpa kepemilikan yang jelas

Penarikan dana dapat gagal karena rekening tujuan tidak valid, penggunaan akun dana yang salah, penundaan transaksi karena tinjauan kepatuhan, atau melewatkan batas waktu jalur. Kegagalan-kegagalan ini berbeda dan tidak terjadi pada waktu yang sama. Namun, pengguna tetap mengharapkan jawaban yang konsisten, dan tim internal tetap perlu menangani prosesnya.

Liquidity and Funding: Money is in the wrong place

Perusahaan yang mengelola beberapa penyedia layanan dan akun harus memastikan bahwa dana yang tepat muncul di akun yang tepat pada waktu yang tepat. Meskipun saldo keseluruhan mencukupi, jika dana tetap berada di akun yang salah, eksekusi pembayaran masih dapat gagal—ini menciptakan jurang antara logika produk dan realitas operasional.

Auditabilitas dan Kontrol: Mengungkap Apa yang Terjadi

Operasi persetujuan, penangguhan, pelepasan, dan rekonsiliasi terjadi lintas tim dan sistem; perusahaan memerlukan catatan yang andal tentang siapa yang melakukan apa, kapan, dan mengapa. Ini bukan hanya persyaratan kepatuhan, tetapi juga dasar untuk melacak riwayat transaksi saat terjadi masalah.

Masalah-masalah ini bersifat operasional maupun arsitektural.

Kegagalan terbesar dalam operasi pembayaran sering terjadi ketika tim tidak dapat menjawab pertanyaan sederhana ini: Uang ini kemana?

Yang hilang bukanlah penyedia layanan lain yang melakukan pembayaran, merutekan transaksi, atau memegang dana dalam model yang ada, melainkan PSP evolusioner yang mampu mengoordinasikan semua fungsi ini, melacak status lintas penyedia layanan, mengelola alur arus dana, dan mempertahankan catatan keuangan yang andal seiring waktu.

Delapan: Evolusi selanjutnya dari PSP

Tantangannya bukan pada akses ke infrastruktur pembayaran, tetapi pada kemampuan untuk memahami secara konsisten dan andal bagaimana dana mengalir di dalamnya.

Pembagian peran dalam ekosistem saat ini: PSP menjalankan pembayaran, bank memegang dana, sistem kepatuhan mengevaluasi risiko, dan alat orkestrasi merutekan transaksi. Namun, tidak ada satu penyedia layanan pun yang bertanggung jawab menyediakan pandangan utuh dan konsisten atas arus dana sepanjang siklus hidup pembayaran.

Arah evolusi berikutnya PSP adalah menyediakan visibilitas konsisten di seluruh tumpukan teknologi—memastikan setiap pembayaran, dari inisiasi hingga penyelesaian akhir, dapat dipahami, dicatat, dan dipercaya.

Lapisan ini harus mampu:

  • Melakukan pembayaran melalui jaringan perbankan silang, tradisional, dan stablecoin
  • Mempertahankan sistem pencatatan yang konsisten melalui buku internal
  • Alur kerja untuk manajemen persetujuan, dana, dan penanganan anomali
  • Rekonsiliasi kegiatan eksternal dengan status keuangan internal
  • Seiring dengan skala yang berkembang, integrasi otomatis dengan kepatuhan, infrastruktur akun, dan jalur pertumbuhan berkelanjutan

Penutup: Di mana harus memulai

Infrastruktur pembayaran modern tidak lagi didefinisikan oleh satu penyedia pemroses atau satu jalur tunggal. Ini adalah lingkungan yang terdiri dari beberapa penyedia layanan, masing-masing bertanggung jawab atas berbagai tahap aliran dana, persetujuan, penyelesaian, dan pencatatan.

Melihat panduan ini, kita melihat evolusi lingkungan ini:

Penyedia pembayaran melampaui ruang lingkup pemrosesan transaksi, jalur pembayaran terus bertambah, sistem real-time menghilangkan jaring pengaman penyelesaian tertunda, dan infrastruktur bentuk baru seperti stablecoin memperluas seluruh sistem lebih jauh.

Bagi tim yang membangun produk keuangan atau mengintegrasikan pembayaran ke dalam perangkat lunak, jalur masuk lebih penting daripada diskusi strategis.

Jangan mulai dari "apakah sepenuhnya menerima stablecoin", tetapi cari masalah spesifik: saluran lintas batas terlalu lambat dalam penyelesaian, proses pembayaran pemasok terlalu banyak melibatkan operasi manual, sebagian dana menganggur tidak menghasilkan keuntungan selama dalam perjalanan. Pilih satu use case, buka satu akun, lakukan satu pembayaran nyata. Mulailah dengan uji coba internal, fokus pada skenario manajemen keuangan (treasury), bukan langsung mengubah proses sisi klien. Dengan begitu, risiko dapat dikendalikan sekaligus membangun pemahaman.

Dari segi kepatuhan, aturan seperti KYC, AML, dan pemindaian sanksi tetap sepenuhnya berlaku; stablecoin hanyalah perubahan pada lapisan dasar. Kerangka regulasi setelah GENIUS Act telah jauh lebih jelas dibanding dua tahun lalu, dan seharusnya tidak menjadi alasan untuk menghambat uji coba.

Risiko strategis sejati bukanlah apakah Anda menggunakan stablecoin atau tidak, tetapi apakah pesaing Anda menggunakan stablecoin untuk merekonstruksi biaya penyelesaian dan efisiensi dana mereka, sementara Anda masih menunggu momen masuk yang sempurna.

Tanpa lapisan koordinasi terpadu, kompleksitas meningkat seiring pertumbuhan skala. Dengan memiliki lapisan ini, perusahaan dapat mengelola arus dana dengan jelas, terkendali, dan penuh kepercayaan.

Sebagian konten berasal dari: Modern Treasury — Panduan Praktis untuk PSPs pada 2026

Penafian: Informasi pada halaman ini mungkin telah diperoleh dari pihak ketiga dan tidak mencerminkan pandangan atau opini KuCoin. Konten ini disediakan hanya untuk tujuan informasi umum, tanpa representasi atau jaminan apa pun, dan tidak dapat ditafsirkan sebagai saran keuangan atau investasi. KuCoin tidak bertanggung jawab terhadap segala kesalahan atau kelalaian, atau hasil apa pun yang keluar dari penggunaan informasi ini. Berinvestasi di aset digital dapat berisiko. Harap mengevaluasi risiko produk dan toleransi risiko Anda secara cermat berdasarkan situasi keuangan Anda sendiri. Untuk informasi lebih lanjut, silakan lihat Ketentuan Penggunaan dan Pengungkapan Risiko.