Seberapa Sulit Membangun Aplikasi Tap to Pay Sendiri? (Kami Mencobanya)

Lebih sulit daripada yang ditunjukkan oleh brosur SDK, dan kesulitannya sebagian besar bukan pada kode. Kami meluncurkan Tap to Pay di aplikasi Final POS, jadi jawaban ini datang dari pengalaman melakukannya langsung, bukan dari membaca dokumentasi. Jika Anda ingin membangun aplikasi tap to pay sendiri, bersiaplah untuk proyek perangkat lunak singkat yang dibungkus dalam proyek izin yang jauh lebih lama: kemitraan pemroses pembayaran, hak khusus manual dari Apple atau evaluasi laboratorium di Android, dan peninjauan aplikasi, semuanya sebelum ketukan langsung pertama Anda.

Catatan singkat: aturan platform dan industri kartu sering berubah. Semua hal di bawah ini akurat pada saat publikasi, jadi anggap detailnya sebagai gambaran saat ini.

Apa yang sebenarnya dilakukan oleh aplikasi tap to pay?

Tap to pay mengubah ponsel itu sendiri menjadi pembaca kartu. Tanpa terminal, tanpa dongle: pelanggan mengetuk kartu nirkontak atau dompet ponsel seperti Apple Pay atau Google Pay langsung di perangkat pedagang, dan pembayaran berjalan melalui chip NFC ponsel (radio jarak pendek yang digunakan untuk nirkontak). Jika terminologinya terasa membingungkan, kami telah menguraikan perbedaan antara pembayaran tap seluler dan Tap to Pay di seluler.

Inilah jebakannya. Membaca tag NFC memang merupakan proyek akhir pekan; para hobiis melakukannya terus-menerus. Membaca kartu pembayaran adalah hal yang sangat berbeda. Kartu menggunakan EMV (protokol chip industri kartu), data kartu harus tetap terenkripsi dari ujung ke ujung, dan hanya perangkat lunak bersertifikat yang diizinkan untuk menyentuhnya.

Mengapa Anda tidak bisa membaca kartu itu sendiri?

Karena setiap lapisan tumpukan teknologi memerlukan izin sebelum kode Anda diizinkan berjalan di publik.

• Apple tidak memberikan akses mentah ke NFC pembayaran kepada aplikasi. Anda harus menggunakan kerangka kerja ProximityReader miliknya, yang berada di balik hak khusus Tap to Pay di iPhone (izin khusus yang diberikan Apple berdasarkan kasus per kasus). Apple juga mengharuskan Anda berintegrasi dengan penyedia layanan pembayaran yang didukung, atau PSP (perusahaan yang benar-benar memindahkan uang). PSP menyediakan konfigurasi pembaca bersertifikat yang dimuat ke perangkat pedagang dan menanggung beban sertifikasi.

• Android memberikan akses NFC yang lebih terbuka kepada pengembang, tetapi aplikasi penerimaan pembayaran masih harus dievaluasi oleh laboratorium independen yang diakui PCI terhadap standar PCI MPoC (aturan keamanan industri kartu untuk ponsel yang bertindak sebagai terminal pembayaran).

• Di bawah kedua platform tersebut, Anda memerlukan hubungan akuisisi: pemroses yang bersedia menyelesaikan uang untuk pedagang Anda, dengan aturan jaringan kartu yang menyertainya.

Semua ini tidak bisa dipaksakan hanya dengan menulis kode yang lebih baik. Ini adalah urusan dokumen, kontrak, dan antrean peninjauan.

Seperti apa jalur persetujuan di iPhone?

Sesuai persyaratan yang diterbitkan Apple, jalurnya berjalan seperti ini: memiliki akun Apple Developer tingkat organisasi (pemegang akun mengajukan permintaan secara pribadi), bermitra dengan PSP yang didukung untuk wilayah Anda, meminta hak khusus, mengintegrasikan API ProximityReader atau SDK PSP Anda, mengikuti panduan desain Apple untuk layar pembayaran, dan mengirimkan aplikasi untuk ditinjau. Dokumentasi Apple juga mencatat bahwa fitur ini hanya berfungsi di negara dan wilayah yang didukung, sehingga ketersediaannya sendiri diputuskan untuk Anda, pasar demi pasar.

Baca daftar itu lagi sebagai pendiri atau pedagang, bukan sebagai pengembang. Tidak ada satu pun langkah yang berupa "menulis fitur". Fitur adalah bagian yang mudah; hak khusus adalah rintangan utamanya.

Ke mana arah pekerjaan setelah fitur tap berfungsi?

Ketukan yang disetujui memberi Anda pembayaran, bukan point of sale. Saat uang bergerak, semua hal di sekitar ketukan harus benar: keranjang belanja tempat uang diselesaikan, pajak pada tanda terima, jalur pengembalian dana, dan pelaporan yang sinkron (setiap dolar cocok dengan penjualan, setiap hari). Kami menemukan kesenjangan yang sama ketika kami melihat apakah Anda bisa membangun POS dengan Lovable atau Replit: menghasilkan antarmuka itu cepat, dan lapisan perdagangan di bawahnya adalah hal yang menyita waktu.

Tap to pay juga membawa keunikan operasionalnya sendiri. Dalam implementasi kami, penjualan harus dimasukkan pada perangkat yang sama yang menerima ketukan, dan ini hanya berfungsi di aplikasi asli, tidak pernah di browser. Batasan seperti itu tidak muncul di brosur mana pun. Anda menemukannya, merekayasa solusinya, lalu menulis artikel bantuan. Dan ketika ponsel di konter tidak lagi cukup, Anda akan masuk ke keputusan perangkat keras yang sebenarnya.

Jadi, seberapa sulit membangun aplikasi tap to pay sendiri?

Sulit dalam hal tertentu: pengodean adalah bagian terkecil, sementara kemitraan pemroses, hak khusus Apple, sertifikasi laboratorium di Android, dan peninjauan aplikasi merupakan bagian terbesar, dan tidak ada satu pun yang merespons upaya rekayasa kode. Bagi kami ini sepadan, karena platform POS menyebarkan biaya tersebut ke setiap pedagang yang menggunakannya. Tap to pay sekarang menjadi tombol checkout yang diaktifkan oleh pedagang kami, dan menerima pembayaran Tap to Pay adalah rutinitas konter lima langkah. Jika pembayaran adalah produk Anda, rintangan tersebut adalah harga masuknya. Jika pembayaran hanyalah cara Anda dibayar, membangun aplikasi tap to pay sendiri tidak masuk akal secara finansial; versi yang sudah jadi sudah ada di dalam aplikasi POS, dan biaya adalah tempat perbandingan yang sebenarnya berada.

Aturan praktis: jika suatu fitur memerlukan izin orang lain untuk ada, tidak ada jalan pintas kode pintar yang bisa melewatinya.