Demo langsung

Pembayaran untuk perisian pelancongan

Integrasi API Paddle: bila merchant of record sesuai untuk perniagaan pelancongan

Paddle menjual perisian, SaaS dan produk digital bagi pihak anda sebagai merchant of record. Ini menjadikannya pilihan kukuh untuk syarikat teknologi pelancongan yang membilkan langganannya sendiri, dan biasanya alat yang salah untuk menerima bayaran bagi penerbangan, hotel dan lawatan. Halaman ini menerangkan perbezaannya, cara integrasi Paddle berfungsi dan cara menyambungkannya ke PHPTRAVELS apabila kes anda sesuai.

  • Merchant of record, bukan gerbang
  • Dibina untuk perisian dan langganan
  • Webhook bertandatangan
  • Disambung sebagai integrasi tersuai

Dua model berbeza

Merchant of record lwn gerbang pembayaran

Gerbang pembayaran memindahkan wang untuk anda: anda ialah penjual, syarikat pembayaran memproses kad, manakala cukai, invois, bayaran balik dan pertikaian kekal menjadi tanggungjawab anda. Merchant of record melangkah lebih jauh dan menjadi penjual pada pandangan pelanggan dan pihak berkuasa cukai. Apabila seseorang membeli melalui Paddle, Paddle yang menjual kepada mereka, mengutip dan menyerahkan cukai jualan atau VAT, mengeluarkan invois, mengendalikan chargeback, kemudian membayar bahagian anda.

Model ini menjimatkan banyak kerja cukai dan pematuhan bagi syarikat perisian, tetapi ia juga bermakna Paddle yang menentukan apa yang sanggup dijualnya. Platformnya dibina untuk perisian, SaaS dan produk digital, bukan perkhidmatan perjalanan yang disediakan oleh syarikat penerbangan, hotel dan pengendali lawatan. Mekanik umum pembayaran kad dibincangkan di halaman API Gerbang Pembayaran.

Gambar rajah aliran pembayaran yang menunjukkan pelanggan membayar dalam talian sementara tanggungjawab pembayaran, cukai dan pembayaran keluar berpindah antara penjual dan penyedia pembayaran
SoalanPaddle (merchant of record)Gerbang pembayaran
Siapa penjual?Paddle ialah penjual rasmi. Resit dan penyata kad pelanggan datang dari pihak Paddle dalam jualan itu.Anda ialah penjual. Gerbang hanya memproses pembayaran pada akaun peniaga anda.
Siapa yang mengendalikan cukai jualan dan VAT?Paddle mengira, mengutip dan menyerahkan cukai jualan serta VAT di tempat ia menjual.Anda, melalui pendaftaran cukai, akauntan dan pengeluaran invois anda sendiri.
Siapa yang mengeluarkan invois?Paddle mengeluarkan invois atau resit kepada pembeli.Sistem anda sendiri mengeluarkannya, contohnya invois tempahan dalam admin anda.
Siapa yang mengendalikan chargeback?Paddle menangani pertikaian dan chargeback sebagai penjual.Anda menjawab pertikaian dengan bukti melalui papan pemuka atau API gerbang.
Apa yang boleh anda jual?Perisian, SaaS, langganan dan produk digital, mengikut peraturan penggunaan boleh diterima Paddle.Jualan barangan dan perkhidmatan yang diluluskan gerbang, termasuk tempahan perjalanan bagi ramai peniaga pelancongan.
Bagaimana anda dibayar?Paddle membayar pendapatan anda selepas ditolak yuran, mengikut jadual pembayaran keluarnya.Bayaran yang diambil diselesaikan ke akaun peniaga atau bank anda, tolak yuran gerbang.

Yuran, negara yang disokong dan senarai tepat produk yang dibenarkan ditetapkan oleh Paddle dan berubah dari semasa ke semasa. Semak terma Paddle sendiri sebelum anda merancang menggunakannya.

Pembantu keputusan

Adakah Paddle sesuai dengan apa yang anda jual?

Mulakan daripada apa yang dibayar oleh pelanggan. Pilih senario yang paling hampir dengan perniagaan anda.

01

Pelancong membayar untuk penerbangan, hotel dan lawatan

Pelanggan membeli perjalanan yang disediakan oleh syarikat penerbangan, hotel atau pengendali lawatan. Bayaran sebegini sering memerlukan kebenaran sekarang dan pengambilan kemudian, bayaran balik separa selepas caj pembatalan dan checkout berbilang mata wang.

Pandangan kami

Gunakan gerbang pembayaran

Semak peraturan penggunaan boleh diterima Paddle sebelum menggunakannya untuk tempahan perjalanan. Kebanyakan perniagaan pelancongan menerima bayaran tempahan melalui gerbang pembayaran seperti Stripe, PayPal, Adyen atau gerbang serantau.

02

Anda menjual perisian pelancongan atau SaaS sendiri

Anda vendor teknologi pelancongan dan agensi membayar langganan bulanan atau tahunan untuk alat tempahan, akses API, pemalam atau portal white label anda.

Pandangan kami

Paddle boleh sesuai

Inilah jenis jualan yang dibina untuk merchant of record: Paddle membilkan langganan, mengendalikan cukai di setiap negara dan membayar anda, supaya anda tidak perlu mendaftar VAT di semua tempat pelanggan anda berada.

03

Anda menjual tempahan dan perisian

Agensi anda menjalankan laman tempahan untuk pelancong dan juga melesenkan platform atau alatannya kepada agensi lain.

Pandangan kami

Guna kedua-duanya, diasingkan

Terima bayaran tempahan melalui gerbang sedia ada dalam aliran tempahan, dan bilkan langganan perisian melalui Paddle. Dua aliran, dua set rekod, masing-masing dengan layanan cukai yang betul.

Cara ia berfungsi

Cara integrasi Paddle berfungsi dari awal hingga akhir

Paddle Billing berfungsi dengan produk dan harga yang anda cipta dalam Paddle, checkout yang dibuka oleh Paddle.js, dan webhook yang memberitahu pelayan anda apa yang berlaku.

  1. 01

    Produk dan harga

    Anda mencipta setiap pelan sekali dalam Paddle, contohnya harga bulanan dan tahunan, dan menyimpan ID harga dalam sistem anda.

    pri_…

  2. 02

    Checkout Paddle.js

    Halaman anda memuatkan Paddle.js dan membuka checkout sebagai tindihan atau bingkai sebaris dengan ID harga dan rujukan pelanggan anda sendiri.

    Paddle.Checkout.open()

  3. 03

    Transaksi selesai

    Pembeli membayar, Paddle mengecas kad atau dompet, mengenakan cukai dan mencipta transaksi, serta langganan jika harga itu berulang.

    txn_…

  4. 04

    Webhook bertandatangan

    Paddle menghantar peristiwa seperti transaction.completed ke endpoint anda, ditandatangani dalam pengepala Paddle-Signature.

    transaction.completed

  5. 05

    Sistem anda bertindak

    Pelayan anda mengesahkan tandatangan, kemudian mengaktifkan akaun, memperbaharui pelan atau merekod bayaran.

    200 OK

Simpan kunci API di pelayan anda sahaja. Pelayar menggunakan token sisi klien yang berasingan, dan persekitaran sandbox serta live masing-masing mempunyai kunci, harga dan rahsia webhook sendiri.

Keselamatan webhook

Menyemak pengepala Paddle-Signature

Webhook boleh dipalsukan oleh sesiapa yang tahu URL endpoint anda. Mengesahkan tandatangan pada setiap peristiwa menjadikan pengaktifan akaun daripada webhook selamat.

paddle-webhook.php
 1$raw    = file_get_contents("php://input"); 2$header = $_SERVER["HTTP_PADDLE_SIGNATURE"] ?? "";  // ts=…;h1=… 3parse_str(str_replace(";", "&", $header), $sig); 4 5$expected = hash_hmac("sha256", $sig["ts"] . ":" . $raw, $endpointSecret); 6if (!hash_equals($expected, $sig["h1"] ?? "")) { 7    http_response_code(400); exit;            // not from Paddle 8} 9if (time() - (int) $sig["ts"] > $tolerance) exit; // too old1011$event = json_decode($raw, true);12if (alreadyHandled($event["event_id"])) exit;      // repeat delivery13if ($event["event_type"] === "transaction.completed") {14    activatePlan($event["data"]["custom_data"]["account_id"]);15}16http_response_code(200);

Contoh ilustrasi dalam PHP biasa. Ikuti dokumentasi semasa Paddle, atau SDK rasminya, untuk format yang tepat.

  1. 01

    Guna badan mentah

    Tandatangan dikira ke atas badan permintaan tepat seperti yang diterima, jadi bacalah sebelum sebarang penghuraian JSON mengubahnya.

  2. 02

    Cap masa serta hash

    Pengepala membawa cap masa dan hash HMAC-SHA256 yang dibuat dengan kunci rahsia endpoint anda. Bina semula dan bandingkan dalam masa tetap.

  3. 03

    Tolak peristiwa lama dan berulang

    Tolak peristiwa yang cap masanya terlalu lama dan simpan ID setiap peristiwa supaya penghantaran berulang tidak diproses dua kali.

  4. 04

    Sandbox dahulu

    Bina dan uji pada sandbox Paddle dengan kad ujian, kemudian tukar kunci, harga dan rahsia kepada live.

PHPTRAVELS dan Paddle

Menyambung Paddle ke PHPTRAVELS

Jawapan jujur dahulu, kemudian pilihannya.

Paddle bukan penyambung siap sedia

Paddle tiada dalam senarai gerbang pembayaran PHPTRAVELS dan tiada panduan persediaan yang diterbitkan. Gerbang siap sedia, yang ditunjukkan di bawah, ialah yang dibina untuk menerima bayaran tempahan.

Tanya tentang integrasi tersuaiCuba demo tempahan

  • Untuk bayaran tempahan: gerbang siap sedia

    Aktifkan gerbang siap sedia seperti Pembayaran Stripe atau Pembayaran PayPal dalam admin dengan akaun peniaga anda sendiri. Checkout, bayaran balik dan rujukan tempahan sudah disambungkan ke aliran tempahan, seperti dijelaskan di halaman Integrasi gerbang pembayaran.

  • Untuk jualan perisian: Paddle sebagai integrasi tersuai

    Apabila kes anda sesuai dengan peraturan Paddle, pembangun kami boleh menyambungkannya sebagai Integrasi API tersuai: checkout Paddle.js pada halaman anda, endpoint webhook yang disahkan dan bayaran direkodkan terhadap pelanggan anda. Kerja ini disebut harga sebelum bermula.

  • Atau bina sendiri di atas kod sumber

    PHPTRAVELS dihoskan sendiri dan disertakan dengan kod sumber penuh, jadi pembangun anda sendiri boleh menambah Paddle untuk langganan di sebelah enjin tempahan. Halaman Harga menyenaraikan apa yang termasuk dalam setiap lesen.

Sedia untuk bayaran tempahan

Gerbang pembayaran yang sudah disambung ke PHPTRAVELS

Untuk bayaran pelancong dan ejen, gerbang ini sudah sedia: anda membuka akaun dengan penyedia, memasukkan kunci dalam admin, menguji dan terus live. Senarai ini ialah senarai langsung daripada direktori integrasi kami.

Sub-ejen juga boleh membayar daripada baki prabayar atau had kredit melalui Dompet ejen B2B, yang tidak memerlukan sebarang gerbang.

Soalan Lazim

Integrasi API Paddle: soalan lazim

Hubungi jualan

Bukan sebagai penyambung siap sedia. Paddle tiada dalam senarai gerbang pembayaran PHPTRAVELS. Jika kes anda sesuai dengan peraturan Paddle, contohnya menjual langganan perisian anda sendiri, ia boleh ditambah sebagai integrasi tersuai atau dibina oleh pembangun anda di atas kod sumber yang disertakan.

Paddle ialah merchant of record yang dibina untuk perisian, SaaS dan produk digital, jadi biasanya ia bukan alat untuk penerbangan, hotel atau lawatan. Semak peraturan penggunaan boleh diterima Paddle sebelum menggunakannya untuk tempahan perjalanan; kebanyakan perniagaan pelancongan menerima bayaran tempahan melalui gerbang pembayaran seperti Stripe, PayPal, Adyen atau gerbang serantau.

Syarikat yang secara sah menjual kepada pelanggan. Ia bertanggungjawab mengutip dan menyerahkan cukai jualan atau VAT, mengeluarkan invois, mengendalikan bayaran balik dan chargeback, dan muncul pada penyata pelanggan. Dengan Paddle, Paddle mengambil peranan itu dan membayar anda.

Gerbang memproses bayaran untuk anda sementara anda kekal sebagai penjual dan menanggung kerja cukai serta pertikaian. Paddle sendiri menjadi penjual, yang menghapuskan kerja itu bagi jualan perisian tetapi menghadkan apa yang boleh anda jual melaluinya.

Apabila anda menjual perisian sendiri dan bukan perjalanan: alat tempahan, API, pemalam atau portal white label yang dibayar agensi melalui langganan. Paddle kemudian boleh membilkan mereka dan mengendalikan cukai di setiap negara.

Paddle menghantar peristiwa seperti transaksi selesai atau langganan diperbaharui ke URL yang anda daftarkan. Setiap permintaan membawa pengepala Paddle-Signature dengan cap masa dan hash, yang disemak pelayan anda dengan kunci rahsia endpoint sebelum bertindak.

Boleh. Paddle mempunyai persekitaran sandbox berasingan dengan akaun, kunci API, harga dan kad ujian sendiri. Bina dan uji di situ, kemudian pindahkan konfigurasi ke persekitaran live.

Boleh, sebagai dua aliran berasingan: enjin tempahan menerima bayaran pelancong melalui gerbang siap sedia, dan Paddle membilkan langganan perisian anda. Asingkan rekod mereka supaya setiap jualan mendapat layanan cukai yang betul.

Terokai lagi

Lagi tentang platform