Airwallex Checkout'u sadece ödeme sayfasının açılabilmesi için kurmak yeterli değildir. Müşteriler, ödeme yapmadan önce satın alma içeriğini, tutarı ve para birimini, tek seferlik mi yoksa periyodik mi ödeme yapılacağını anlamalıdır; ödeme yaptıktan sonra da siparişin nasıl onaylanacağını, ne zaman teslim edileceğini ve nasıl destek alacağını bilmeli. Bu makale, şirketlerin gerçek satış yaptığı ürün veya hizmetlere göre müşteri perspektifinden kontrol yöntemlerini derler, ancak ödeme başarısı, platform onayı veya iş sonuçlarını garanti etmez.
Önce gerçek faturalandırma yöntemine uygun Checkout modunu seçin.
Airwallex resmi olarak Checkout'u müşterilerin satın alma sürecinin son adımı olarak tanımlar, müşteriler satın alma içeriğini onaylar, ilgili faturalandırma yöntemini seçer ve ödeme bilgilerini gönderir. Yapılandırmaya başlamadan önce, şirket içinde bu işlemin tek seferlik ödeme mi, abonelik ilişkisi mi yoksa sadece gelecekte kullanılmak üzere ödeme yöntemini kaydetmek mi olduğu konusunda netleşmeli; işin gerçek faturalandırma yöntemi, sayfa, sipariş açıklaması ve sonraki bildirimlerle uyumlu olmalıdır.
Tek seferlik hizmeti otomatik yenileme olarak yazmayın ve devam eden faturalandırmayı belirsiz ürün adlarıyla gizlemeyin. İşiniz deneme, rezervasyon, taksitli ödeme veya abonelik içeriyorsa, iş, müşteri hizmetleri ve teknik personel birlikte faturalandırmayı tetikleyen koşulları, periyodu, iptal girişini ve müşteri bildirimlerini onaylamalı ve ardından mevcut hesapta kullanılabilir olan işlevlere ve resmi açıklamalara göre uygulamalıdır.
Ürünleri, fiyatları, para birimlerini ve miktarları müşterilerin bir bakışta anlayabileceği şekilde sunun.
Her bir Checkout bağlantısı veya oturumu, gerçekte teslim edilebilir bir ürün veya hizmete karşılık gelmelidir. Adlar, içsel kod adlarından kaçınılmalı, fiyatlar, resmi web sitesi veya fiyat listesiyle uyumlu olmalı, para birimi, miktar, vergiler, kargo ücretleri veya olası periyodik ödemeler de müşterinin ödeme yapmadan önce açıkça açıklanmalıdır. Sadece bir tutar vermek ve neyin dahil olduğunu açıklamamak, müşterinin doğru seçim yapıp yapmadığını değerlendirmesini zorlaştırır.
Eğer aynı iş alanında farklı paketler, bölgesel sürümler veya hizmet süreleri satılıyorsa, ayrı ayrı net ürün açıklamaları ve fiyat mantığı oluşturulmalı ve güncelleme sorumlusu atanmalıdır. Yayına alınmadan önce, üretime katılmayan bir kişi müşteri yolculuğuyla okumalı: Müşteri ne aldığını, ne kadar ödediğini ve hizmeti ne zaman alacağını söyleyebilir mi? Eğer yapamazsa, ödemeyi açmadan önce açıklamaları tamamlayın.
Teknik yeteneğe göre barındırılan sayfa, entegre bileşen veya özel entegrasyon seçin
Airwallex'in mevcut dokümantasyonunda, barındırılan Hosted Billing Checkout, entegre Elements, yerel API ve mobil SDK gibi entegrasyon yöntemleri listelenmiştir. Barındırılan sayfalar genellikle Airwallex tarafından sağlanır; sunucu tarafında Checkout nesnesi oluşturulduktan sonra müşteri özel bir bağlantıya yönlendirilir. Entegre bileşenler veya özel arayüzler, takımın daha fazla sayfa, test ve bakım işi üstlenmesini gerektirir. Seçim yaparken, takımın gerçek mühendislik yeteneği ve sonraki bakım sorumluluğu esas alınmalıdır.
Hangi entegrasyon yöntemi seçilirse seçilsin, satıcılar müşteri bilgisi gösterme ve sonrası sorumluluğunu teknolojik yapıya bırakamazlar. Ürün açıklamalarını, politika bağlantılarını, müşteri hizmetleri e – postasını ve hata uyarılarını kimlerin yöneteceğini belirlemelidir. Herhangi bir yönlendirme, entegrasyon veya geri dönüş sayfası değişikliğinden sonra, mobil ve masaüstü cihazlarda yeniden kontrol edilmeli ve müşterinin ödeme yaptıktan sonra geçersiz bir sayfaya düşmemesi ve işletmeyle iletişim kuramamaması sağlanmalıdır.
Teslimat, iade ve iptal kurallarını uygulanabilir bir taahhütte yazın
Fiziksel ürünler, dijital içerikler, randevu hizmetleri ve abonelikler farklı teslimat beklentilerine sahiptir. Fiziksel ürün işleri, teslimat alanını ve tahmini planı açıklamalıdır; dijital hizmetler, açılış veya teslimat şeklini açıklamalıdır; randevular, randevu değiştirme ve iptal pencerelerini açıklamalıdır; abonelikler ise müşterinin her ödeme aralığını ve sonraki ödemeleri durdurma yollarını anlamasını sağlamalıdır. Tüm süreler ve koşullar, takımın gerçekten uygulayabileceği süreçlerden gelmelidir.
İade veya iptal politikaları ayrı bir sayfada yer alabilir, ancak ödeme öncesi müşteri tarafından bulunabilir olmalı ve ürün sayfası, ödeme sayfası, onay e – postası ve müşteri hizmetleri yanıtlarıyla çelişmemelidir. Diğer sektörlerin evrensel hükümlerini kopyalamayın ve ödeme kanalının kabul edebileceği işlem sürelerini, şirketin garantileyebileceği nakit girişi tarihi olarak ifade etmeyin; daha faydalı olan, şirketin ne zaman işleyeceğini, müşterinin hangi sipariş bilgilerini sağlaması gerektiğini ve nasıl takip edeceğini açıklamaktır.
Ödeme başarılı sayfası müşteriye bir sonraki adımda ne olacağını söylemelidir.
Ödeme tamamlanması müşteri yolculuğunun sonu değildir. Başarılı sayfa veya sonraki bildirimler, sipariş onayının nereye gönderileceğini, teslimat veya etkinleştirmenin beklenen şeklini, müşterinin bilgilerini değiştirip değiştiremeyeceğini ve sorun oluştuğunda hangi destek kanalıyla iletişime geçileceğini açıkça belirtmelidir. Müşteriden ek olarak kayıt yapması, belge yüklemesi veya randevu alması gerekiyorsa, amaç, giriş yolu ve tamamlanma süresi de açıklanmalıdır, sadece genel bir "Ödeme başarılı" mesajı göstermek yerine.
Ödeme sonrası bildirim içeriği, gerçek arka plan durumuyla eşleşmelidir. Sözleşme yerine getirilmemişken "Gönderildi" veya "Hizmet etkinleştirildi" yazmaktan kaçının ve dahili otomasyon başarısızlığı nedeniyle müşterinin mevcut olmayan sipariş numarasını görmesine neden olmayın. Ekip, normal müşteri hizmetleri ve sorun giderme için sipariş, müşteri iletişimi ve gerçek teslimat kayıtlarını saklayabilir, geride kalan zamanlarda gerçek olmayan açıklamalar üretmek yerine.
Sadece sözleşme yerine getirme için gerekli bilgileri toplayın ve müşteri verilerini koruyun.
Satın alma sürecini tasarlarken, her form alanının gerçekten teslimat, vergi veya müşteri desteği için hizmet verip vermediğini tek tek gözden geçirin. Müşteri adı, iletişim bilgileri veya adresi gibi veriler, mevcut ürün tarafından sağlanan uygun standart yetenekler aracılığıyla toplanmalı ve müşteriye kullanım amacı açıklanmalıdır; içsel filtreleme kolaylığı için siparişle ilgili olmayan gizlilik bilgileri toplanmamalıdır.
Müşteriden ürün notu, özel açıklama veya müşteri hizmetleri sohbetinde şifre, doğrulama kodu, tam banka kartı bilgileri, kimlik belgesi görüntüsü veya diğer hassas materyaller istemeyin. İşletmenin düzenlenmiş bir bilgi işleme ihtiyacı varsa, önce uygunluk ve güvenlik sorumlularından yasal temeli, saklama şeklini, erişim alanını ve silme süresini onaylatın ve hesap içindeki ve resmi belgelerdeki mevcut gereksinimlere göre hareket edin.
Canlıya çıkarmadan önce uçtan uca müşteri perspektifinden bir inceleme yapın.
Canlıya çıkarmadan önce izin verilen test ortamı veya test sürecini kullanarak sırayla kontrol edin: Bağlantılar açılabiliyor mu, ürün adı ve tutarı doğru mu, para birimi açık mı, politikalar erişilebilir mi, müşteri desteği etkili mi, ödeme sonrası sayfa ve bildirimler doğru mu. Test sırasında test verileri veya yetkili dahili veriler kullanılmalıdır, müşteri gerçek ödeme bilgileri geçici denemeler için kullanılmamalıdır.
Bu yeniden denetimin tarihini, bağlantısını, sorumlu kişiyi, sayfa sürümünü ve tespit edilen sorunları kaydedin. Bundan sonra fiyat, paket, teslimat şekli, politika, destek e-postası veya teknik entegrasyon değiştiğinde, aynı yolu tekrar izlemelisiniz. Net ödeme bilgileri, gerçek sözleşme yerine geçemez ve uygunlukta faaliyet göstermez, ancak müşterilerin bilinçli kararlar vermelerine yardımcı olabilir ve önlenebilir iletişim maliyetlerini azaltabilir.
Resmi Belgeler ve Sıkça Sorulan Sorular
Bu metnin son kontrol tarihi 2026 Eylül'dür. Platform kuralları, kullanılabilir bölgeler, belge gereksinimleri, ücretler ve onay süreçleri değişebilir; Lütfen sadece Airwallex Resmi Ödeme Sayfası İşlevi Açıklaması Hesap içindeki bildirimlere göre hareket edin ve sadece gerçek, geçerli ve şirketin kendisine ait olan belgeleri gönderin.
Airwallex Ödeme Sayfası, tek seferlik ödeme ve abonelik için kullanılabilir mi?
Airwallex'in mevcut resmi açıklaması, PAYMENT, SUBSCRIPTION ve SETUP gibi modları listeler. Kullanılabilir modlar ve spesifik yapılandırmalar, şirket hesabına, bölgeye ve mevcut ürün arayüzüne göre belirlenmelidir ve gerçek faturalandırma yöntemi ve müşteri açıklamalarıyla uyumlu olmalıdır.
Barındırılan ödeme sayfasını başlattıktan sonra, satıcıların daha neleri yönetmesi gerekir?
Hala da gerçek ürün açıklamaları, fiyatlar, para birimleri, teslimat ve iade kuralları, müşteri desteği ve ödeme sonrası bildirimler korunmalıdır. Yönetilen sayfalar bazı geliştirme çalışmalarını azaltabilir, ancak satıcıların satış içeriği ve sonrası sorumluluklarını yerine getiremez.
Ödeme başarılı sayfasına hangi bilgiler yazılmalıdır?
En azından müşteriye siparişin nasıl onaylanacağı, sonraki teslimat veya etkinleştirme yöntemi, tahmini planlama ve kullanılabilir destek kanalları hakkında bilgi verilmelidir. Bilgiler gerçek sipariş durumunu yansıtmalıdır, gerçek ilerlemeyi yerine henüz tamamlanmamış taahhütler kullanılamaz.
Canlıya çıkarmadan önce doğrudan müşterinin banka kartıyla test yapılabilir mi?
Geçici testler için müşteri gerçek ödeme bilgilerini toplamak veya kullanmak önerilmez. Öncelikle platformun izin verdiği test ortamı, test verileri veya yetkili iç süreçler kullanılmalı ve mevcut resmi belgelere göre testler tamamlanmalıdır.