Base Üzerinden Kripto Ödemeleri Nasıl Kabul Edilir: İşletmeler İçin Rehber

Base Üzerinden Kripto Ödemeleri Nasıl Kabul Edilir: İşletmeler İçin Rehber

Author: Xi Wang
Created:

Base üzerinden kripto ödemelerini güvenilir biçimde kabul etmek için bir işletmenin yalnızca Base cüzdan adresine sahip olması yetmez. Kullanılabilir bir ödeme akışının doğru token'ı ve ağı belirlemesi, doğru tutarı talep etmesi, aktarımı algılaması, uygun bir onay durumunu beklemesi, ödemeyi siparişle eşleştirmesi ve siparişin birden fazla kez teslim edilmesini önlemesi gerekir.

Base, hâlihazırda Ethereum uyumlu cüzdan kullanan ve varlıklarını bu ağda tutan müşteriler için kullanışlı bir ödeme ağı olabilir. EVM tabanlıdır, gas ücreti için ETH kullanır ve ana ağ zincir kimliği 8453 değeridir. Ethereum ile bu benzerlikler Base'i tanıdık kılar ancak yaygın bir hata olasılığı da yaratır: Müşteri yanlış ağı seçmiş olsa bile bir 0x adresi birden fazla ağda geçerli görünebilir.

Bu rehber; USDC, token sözleşmesi doğrulama, ödeme sayfası seçenekleri, webhook'lar, iadeler ve muhasebe konularına odaklanarak işletmeler için Base ödemelerinin nasıl kurulacağını açıklar. Herhangi bir ödeme seçeneğini yayımlamadan önce, ilgili token ve ağ birleşiminin kimlik doğrulamalı ödeme ayarlarınızda yer aldığını teyit edin. Herkese açık Base ağ sayfası yararlı bir bağlam sunar ancak her varlığın her hesapta etkin olduğunun kanıtı değildir.

Base üzerinden ödeme kabul etmek gerçekte neleri içerir?

Base, Ethereum'un ikinci katman ağıdır. Ethereum tarzı hesapları, akıllı sözleşmeleri, cüzdanları ve token standartlarını destekler. Resmî Base bağlantı belgelerine göre Base ana ağı şunları kullanır:

  • ağ adı: Base Mainnet;
  • zincir kimliği: 8453;
  • gas para birimi: ETH;
  • blok gezgini: BaseScan.

Dolayısıyla bir Base ödemesinin birbirinden ayrı birkaç alanı vardır:

  1. Ağ: Ethereum ana ağı veya başka bir EVM ağı değil, Base ana ağı.
  2. Varlık: ETH ya da USDC gibi belirli bir token.
  3. Token sözleşmesi: Varlık, yerel ETH yerine bir token olduğunda gereklidir.
  4. Hedef: İşletmenin Base uyumlu tahsilat adresi.
  5. Tutar: Sipariş için beklenen tam tutar.
  6. Ödeme referansı: Aktarımı bir müşteriye, faturaya veya satın alma işlemine bağlayan kayıt.
  7. Durum: Ödeme sisteminin tanımladığı beklemede, onaylandı, eşleşmedi, süresi doldu veya başka bir durum.

Geçerli görünen bir adres, ağı belirlemez. Ethereum, Arbitrum veya başka bir EVM zincirinde aynı 0x adresine gönderilen işlem, Base ödemesine dönüşmez. Ödeme sayfanız, destek talimatlarınız ve muhasebe kayıtlarınız her zaman hem varlığı hem ağı belirtmelidir; örneğin “Base üzerinde USDC.”

İşletmeler neden Base'i tercih ediyor?

Müşterilerin kayda değer bir bölümü zaten Base kullanıyorsa bu ağı denemek mantıklıdır. Olası kullanım alanları arasında geliştirici araçları, çevrim içi hizmetler, dijital ürünler, ücretli topluluklar, hesap kredileri ve kriptoya aşina müşterilere kesilen faturalar bulunur.

Pratik avantajları şunlardır:

  • bilinen EVM cüzdanları ve adresleri;
  • gas varlığı olarak ETH kullanılması ve Ethereum kullanıcılarının buna zaten aşina olabilmesi;
  • yerel USDC dâhil token desteği;
  • işlemleri BaseScan üzerinden inceleme olanağı;
  • hiçbir ücret için garanti verilemese de genellikle Ethereum ana ağından daha düşük olabilen işlem maliyetleri.

Son maddeye dikkatle yaklaşmak gerekir. “Genellikle daha ucuz”, “her zaman ucuz” demek değildir. Ücret, mevcut ağ koşullarına ve işleme bağlıdır. Varlıkları başka bir zincirde bulunan müşteri, Base'e geçmeden önce borsadan çekim veya köprü kullanma maliyetleriyle de karşılaşabilir. Yalnızca son aktarım için gösterilen gas tahminini değil, müşterinin izlediği yolun tamamını karşılaştırın.

Müşteriler Base üzerinde varlık tutmuyorsa, kullandıkları borsa Base'e çekim olanağı sunmuyorsa veya bilmedikleri köprü adımlarını izlemeleri gerekiyorsa Base iyi bir varsayılan seçenek değildir. Ağlar arasında hâlâ karar veriyorsanız Base'i herkese uygun tek çözüm saymak yerine daha kapsamlı stablecoin ödemeleri için en iyi blok zinciri rehberinden yararlanın.

USDC, ETH veya desteklenen başka bir token seçin

Ağ seçimi ile varlık seçimi birbirinden ayrıdır. Müşteri Base üzerinde yerel ETH gönderebilir veya Base'teki bir token sözleşmesi üzerinden aktarım yapabilir. Ödeme yöntemi her ikisini de belirtmelidir.

Base üzerinde USDC

USDC, ABD doları cinsinden fiyatlandırılan bir ürün için çoğu zaman en anlaşılır başlangıç noktasıdır. 50 USD'lik referans fiyat, müşteriyi ETH cinsinden bir ödemedeki kısa vadeli kur hareketine aynı ölçüde maruz bırakmadan 50 USDC talebine dönüşebilir. Bununla birlikte USDC; ihraççı, sözleşme, sabit değerini kaybetme, mevzuat, cüzdan ve ağ riskleri taşır. “Stablecoin”, risksiz anlamına gelmez.

Circle'ın resmî USDC sözleşme dizini, Base üzerindeki yerel USDC'yi şu adreste listeler:

0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913

Token adı ve sembolü benzersiz tanımlayıcılar olmadığı için sözleşme doğrulaması önemlidir. Cüzdanlar benzer görünümlü varlıklar gösterebilir, köprülenmiş sürümler ise farklı sözleşmeler kullanabilir. Entegrasyonunuz, yalnızca ekranda “USDC” yazan herhangi bir token'ı değil, ödeme akışının desteklediği kesin sözleşmeyi tanımalıdır.

Yerel USDC ile köprülenmiş USDC arasındaki fark

Yerel USDC, hedef ağ için ihraç edilir ve Circle'ın dizinindeki sözleşmeyle tanımlanır. Köprülenmiş token ise bir köprü aracılığıyla taşınan varlığı temsil eder; farklı bir sözleşmeye, ihraççı ilişkisine, likidite yapısına ve geri ödeme yoluna sahip olabilir.

Adları veya değerleri benzer göründüğü için yerel ve köprülenmiş USDC'yi birbirinin yerine kullanmayın. Base USDC'yi etkinleştirmeden önce:

  1. kimlik doğrulamalı işletme ayarlarındaki varlık seçeneğini eksiksiz okuyun;
  2. sözleşmeyi Circle'ın güncel diziniyle karşılaştırın;
  3. müşterinin cüzdanında veya işleminde gösterilen sözleşmeyi doğrulayın;
  4. ödeme sisteminin bu kesin sözleşmeyi tanıyıp tanımadığını test edin;
  5. destek ekibinin desteklenmeyen köprülenmiş bir varlığı nasıl ayırt edeceğini belgeleyin.

Sözleşme desteklenen rotayla eşleşmiyorsa siparişi otomatik olarak ödenmiş saymayın. Aktarımı incelemeye alın. Para adreste bulunabilir ancak yine de işletmenin kabul ettiği ödeme kurallarını karşılamayabilir.

Base üzerinde ETH

ETH, Base'in yerel gas varlığıdır ve bu seçenek açıkça sunulduğunda ödeme olarak da kabul edilebilir. Base üzerinde zaten ETH tutan alıcılar veya bilerek ETH cinsinden fiyatlandırılmış ürünler için uygundur.

İtibari para cinsinden fiyatlandırılan ürünlerde ETH, kur oynaklığı yaratır. Ödeme sayfası kesin ETH tutarını hesaplamalı, fiyat teklifinin ne zaman sona ereceğini göstermeli ve geç, eksik ya da fazla ödemelerde ne olacağını tanımlamalıdır. Fiyat değiştikten sonra eski bir ETH teklifini yeniden kullanmayın.

Diğer token'lar

Başka bir token'ı yalnızca aşağıdaki koşulların tümü sağlandığında sunun:

  • Base üzerindeki ilgili token kimlik doğrulamalı ayarlarda açıkça yer alıyorsa;
  • gerçek müşteri talebi varsa;
  • tahsilat cüzdanı ve finans süreci bu sözleşmeyi destekliyorsa;
  • ekibiniz bunu fiyatlandırabiliyor, onaylayabiliyor, mutabakata alabiliyor ve iade edebiliyorsa;
  • ödeme sayfası token'ı benzer ad taşıyan veya köprülenmiş varlıklardan açıkça ayırıyorsa.

“Base üzerindeki tüm token'ları” kabul ettiğinizi duyurmayın. Teknik olarak aktarılabilir olmak, ödeme sayfasında desteklenmekle aynı şey değildir.

Müşteri ödeme yapmadan önce Base gas ücretini açıklayın

Base üzerindeki hem ETH hem token ödemeleri gas gerektirir. Gas ücretinin işletme tarafından karşılanmadığı ve ERC-20 ile gas ödemesinin desteklenmediği sıradan bir aktarımda, göndericinin ağ ücreti için Base üzerinde ETH bulundurması gerekir. Müşterinin satın alma tutarını karşılayacak kadar USDC'si olsa bile cüzdanında Base ETH bulunmadığı için işlemi gönderememesi mümkündür.

Üç tutarı birbirinden ayrı tutun:

  • işletmenin alması gereken satın alma tutarı;
  • cüzdanın tahmin ettiği ağ ücreti;
  • ödeme sayfasında açıklanan hizmet sağlayıcı veya işletme ücreti.

Örneğin sipariş 40 USDC talep ediyorsa işletme 40 USDC almalıdır. Cüzdanda gas için ayrıca ETH bakiyesi bulunmalıdır. Müşteriye tahmini ücreti USDC tutarından düşmesini söylemeyin.

Gas hakkında talimat vermeden önce etkin ödeme sayfasını kontrol edin. Gas ücretinin işletme tarafından karşılanmadığı ve ERC-20 ile gas ödemesinin desteklenmediği sıradan bir aktarım kullanılıyorsa yalnızca “ETH gerekir” demek yerine “Ağ ücreti için Base üzerinde ETH gerekir” ifadesini kullanın. Yalnızca Ethereum ana ağında tutulan ETH, Base'e aktarılana kadar Base gas ücretini ödeyemez. Her ikisi de değişebileceğinden sabit ücret veya onay süresi vaat etmeyin.

Base ödemeleri nasıl kurulur?

1. Etkin Base seçeneklerini doğrulayın

Kimlik doğrulamalı işletme ayarlarını açın ve hesabınıza sunulan Base birleşimlerini kesin olarak belirleyin. Yapılandırma ekranının yanı sıra ödeme sayfasını da kontrol edin. Base üzerinde USDC veya Base üzerinde ETH seçeneği yoksa bunu kabul edilen yöntem olarak yayımlamayın.

Gösterilen varlık adını, ağı ve varsa sözleşme ayrıntılarını kaydedin. Herkese açık ağ ve coin sayfaları araştırmayı destekleyebilir ancak hesabınız için geçerli olan kaynak, etkin ayarlardır.

2. Kontrollü bir tahsilat cüzdanı yapılandırın

İşletmenin kontrol ettiği Base uyumlu bir cüzdan kullanın. Adresi karakter karakter doğrulayın ve ardından şunları tanımlayın:

  • tahsilat adresini kimlerin görebileceği ve değiştirebileceği;
  • giden iadeleri veya hazine aktarımlarını kimlerin onaylayabileceği;
  • anahtarların veya imzalama cihazlarının nasıl yedekleneceği;
  • onaylar için birden fazla kişinin gerekip gerekmediği;
  • adres değişikliklerinin nasıl inceleneceği ve kaydedileceği;
  • finans ekibinin Base bakiyelerini diğer ağlardan nasıl ayrı izleyeceği.

Varlıkların saklanmadığı tahsilat modeli, hizmet sağlayıcı bakiyesinden para çekme adımını ortadan kaldırır; ancak anahtar yönetimi veya hazine sorumluluğunu ortadan kaldırmaz.

3. Ödeme linki veya entegre ödeme sayfası seçin

Bir kripto ödeme linki, pilot uygulama, danışmanlık faturası, özel satış veya elle teslim edilen hizmet için en hızlı ve düzenli seçenektir. İşletmeyi eksiksiz bir ödeme sayfası geliştirmeye zorlamadan ödemeye bir tutar ve ticari bağlam kazandırır.

Ödemenin bir hesabı otomatik olarak etkinleştirmesi, dosya teslim etmesi, kredi eklemesi veya siparişi güncellemesi gerekiyorsa entegre ödeme sayfası daha uygundur. Uygulama aşağıdaki verileri oluşturmalı veya saklamalıdır:

  • sipariş veya fatura kimliği;
  • dahili müşteri veya hesap kimliği;
  • ürün ve fiyat;
  • talep edilen token ve ağ;
  • gerektiğinde token sözleşmesi;
  • hedef ve kesin tutar;
  • fiyat teklifinin oluşturulma ve sona erme zamanı;
  • ödeme durumu ve işlem tanımlayıcısı.

Abonelik akışını yalnızca gereken Base ödeme birleşimi kimlik doğrulamalı ayarlarda yer alıyorsa ve ürün tekrarlayan erişim ya da yenileme kayıtları gerektiriyorsa kullanın. Belirli bir cüzdandan çekim yönteminin var olduğunu varsaymayın. Erişim, tolerans süreleri, geciken ödemeler, iptal ve yinelenen yenileme olayları için ürünün kendi kurallarını tanımlayın.

4. Ödeme sayfasında Base'i açık ve net biçimde belirtin

Ödeme sayfasında token'ın, tutarın, QR kodunun ve cüzdan işleminin yanında “Base” ifadesini tekrarlayın. Teknik yardım metninde veya cüzdan kurulum talimatlarında zincir kimliği 8453 değerini belirtin; ancak her müşterinin sayısal zincir kimliğini elle doğrulamasını beklemeyin.

İyi ödeme sayfası metinleri arasında şunlar bulunur:

  • “Base üzerinden 75 USDC gönderin”;
  • “Yalnızca Base ana ağını kullanın”;
  • “Gas ücreti için Base üzerinde ETH gerekir”;
  • uygun olduğunda kesin tutar ve son geçerlilik zamanı;
  • desteklenmeyen bir ağdan gönderim yapılmaması için uyarı.

Müşteriler ağ seçebiliyorsa Base'i görünmez biçimde önceden seçmeyin. Cüzdan açılmadan önce seçimi açık hâle getirin. Ayrıntılı yanlış ağda kripto ödemelerini önleme rehberi; etiketleri, kanıt toplamayı ve olay yönetimini ele alır.

5. Ödeme akışının tamamını düşük tutarlı bir ödemeyle test edin

Yalnızca cüzdan adresini kontrol etmek yeterli değildir. Müşterilerin kullanacağı ödeme akışının aynısını izleyerek düşük tutarlı gerçek bir işlem gerçekleştirin. Şunları doğrulayın:

  1. sayfada doğru token ve Base ağı gösteriliyor;
  2. cüzdan zincir kimliği 8453 olan ağa geçiyor;
  3. hedef ve tutar doğru;
  4. USDC aktarımı beklenen sözleşmeyi kullanıyor;
  5. cüzdan ETH gas ücretini ayrı gösteriyor;
  6. ödeme hemen teslim edilmiş sayılmak yerine beklemede görünüyor;
  7. onaylanmış durum sipariş sistemine ulaşıyor;
  8. yinelenen olay gönderimi siparişin birden fazla kez teslim edilmesine yol açmıyor;
  9. finans ekibi işlemi tahsilat cüzdanında ve BaseScan'de bulabiliyor;
  10. iade süreci amaçlanan onay denetimleri altında çalışıyor.

Tahsilat cüzdanını, ödeme sayfası entegrasyonunu, desteklenen token'ı, olay uç noktasını veya teslimat mantığını değiştirdikten sonra testi tekrarlayın.

Onaylar, webhook'lar ve yinelenmeye dayanıklı teslimat

İşlem karması, araştırılması gereken bir kanıttır; ürünü teslim etme talimatı değildir. İşlemler beklemede kalabilir, başarısız olabilir ya da talep edilen varlık, ağ, hedef, tutar veya siparişle eşleşmeyebilir.

Yazılı bir kabul denetimi tanımlayın:

  • ağ Base ana ağıdır;
  • token veya yerel varlık taleple eşleşir;
  • gerektiğinde token sözleşmesi eşleşir;
  • hedef, yapılandırılmış cüzdanla eşleşir;
  • alınan tutar sipariş politikasını karşılar;
  • işlem gerekli ödeme durumuna ulaşmıştır;
  • işlem daha önce başka bir siparişi ödemek için kullanılmamıştır;
  • sipariş daha önce teslim edilmemiştir.

Ödeme akışının sağladığı onaylanmış durumu kullanın ve sipariş değeri ile teslimat riskine uygun ek politikaları uygulayın. Her durum için geçerli tek bir onay sayısı veya garanti edilmiş saniye süresi vaat etmeyin.

Webhook'larda, entegrasyonun belgelenmiş yöntemini kullanarak kaynağın gerçekliğini doğrulayın. Olay kimliğini, ödeme referansını ve işlem tanımlayıcısını saklayın. Olayı kalıcı bir işlem içinde ele alın, ardından teslimatı yalnızca bir kez tamamlanmış olarak işaretleyin.

Yinelenmeye dayanıklılık, aynı bildirimin tekrar gönderilmesinin tek gönderimle aynı nihai sonucu üretmesi demektir. Aynı onaylanmış olay üç kez ulaşırsa müşteri üç değil; bir lisans, bir kredi tahsisi veya bir erişim uzatması almalıdır. Ödeme ya da olay tanımlayıcısına uygulanan veritabanı benzersizlik kuralı ile kaydedilmiş teslimat durumunu birlikte kullanmak yararlı bir yöntemdir.

Yalnızca webhook'lara güvenmeyin. Oluşturulan ödeme taleplerini, onaylanmış ödeme kayıtlarını, Base işlemlerini ve teslim edilen siparişleri karşılaştıran bir mutabakat görevi veya manuel süreç ekleyin. Böylece doğrulanmamış bir cüzdan aktarımını ödeme saymadan kaçırılan olayları ve dahili işleme hatalarını yakalayabilirsiniz.

Eksik, geç ve yinelenen ödemeleri açıkça ele alın

Ticari politikanıza Base karar vermez. Hizmeti başlatmadan önce şu durumları tanımlayın:

  • Eksik ödeme: Siparişi ödenmemiş veya incelemede tutun; fiyatı sessizce düşürmeyin.
  • Fazla ödeme: Gerçek tutarı kaydedin ve belgelenmiş bir inceleme veya iade politikası uygulayın.
  • Geç ödeme: Süresi dolmuş fiyat teklifini kabul edip etmeyeceğinize, fark isteyip istemeyeceğinize veya iade yapıp yapmayacağınıza karar verin.
  • Yinelenen ödeme: Siparişi bir kez teslim edin, ek aktarımı ayrıca inceleyin.
  • Yanlış token: Desteklenmeyen bir sözleşme için otomatik bakiye tanımlamayın.
  • Yanlış ağ: Kanıt toplayın ve kontrollü bir olay süreci izleyin; kurtarma olanaksız veya güvensiz olabilir.

Destek personeli, yalnızca müşteri ekran görüntüsü gönderdi diye ödeme durumunu değiştirmemelidir. Sipariş referansına ve bağımsız olarak doğrulanmış işlem verilerine ihtiyaçları vardır.

İadeler ve mutabakat

Onaylanmış bir Base aktarımı, kart ağı üzerinden yapılan ters ibrazla geri alınmaz. İade, blok zincirinde yeni bir giden işlemdir. Doğru varlık, Base ağı, hedef, tutar, onay, gas ve muhasebe kaydı gerektirir.

İade yapmadan önce:

  1. asıl siparişi ve onaylanmış işlemi doğrulayın;
  2. onaylanan iade tutarını ve token'ı teyit edin;
  3. kimlik doğrulamalı bir müşteri süreci aracılığıyla hedefi doğrulayın;
  4. iade işlem ücretini kimin karşılayacağını belirtin;
  5. gerekli dahili onayı alın;
  6. giden işlemi asıl tahsilattan ayrı kaydedin.

Beklenmeyen bir e-posta veya destek mesajındaki iade adresini kopyalamayın. Ödemeyi yapan adres, hesap sahibi ve istenen hedef birbirinden farklı olabilir; ayrıca bir saldırgan hedefi değiştirmeye çalışabilir.

Her ödeme için şunları saklayın:

  • sipariş, fatura ve müşteri referansları;
  • token, token sözleşmesi ve Base ağı;
  • alınan kripto tutarı;
  • işletmenin referans para birimi, değerleme ve zaman damgası;
  • hedef adres ve işlem karması;
  • ödeme ve onay zaman damgaları;
  • durum değişiklikleri ve teslimat kaydı;
  • işletmenin kaydettiği hizmet sağlayıcı ve ağ ücretleri;
  • ilgili iade veya düzeltme işlemleri.

Bu kayıtları, işlem hacmine uygun bir programla tahsilat cüzdanı ve sipariş defteriyle mutabakata alın. Desteklenmeyen token'lar, eksik ödemeler, yinelenen ödemeler ve açıklanamayan aktarımlar gibi istisnaları ayrı bir inceleme kuyruğunda tutun. Vergi ve muhasebe uygulamaları yargı alanına göre değişir; değerleme ve raporlama kuralları için yetkin bir danışmana başvurun.

Base ödemelerini kabul ederken sık yapılan hatalar

Yalnızca “USDC” veya “kripto” ifadesini göstermek

Bir sembol, ağı veya sözleşmeyi tanımlamaz. “Base üzerinde USDC” ifadesini gösterin ve desteklenen sözleşmeyi doğrulayın.

Aynı adresin aynı ödeme rotası anlamına geldiğini varsaymak

Bir 0x adresi EVM ağlarında aynı görünebilir. Yine de işlem, gönderildiği zincire aittir.

Köprülenmiş benzer bir varlığı yerel USDC olarak kabul etmek

Sözleşmeyi Circle'ın dizini ve ödeme ayarlarının tanıdığı kesin varlıkla karşılaştırın. Eşleşmeyenleri incelemeye alın.

Token ödemelerinin ETH gerektirdiğini unutmak

Sıradan bir token aktarımında USDC, Base gas ücretini ödemez. Müşterilere Base üzerinde az miktarda ETH gerektiğini söyleyin.

Yönlendirme veya ekran görüntüsüne dayanarak teslimat yapmak

Tarayıcının dönüş sayfası ve cüzdan onay ekranı, doğrulanmış ödeme durumu değildir. Eşleşen onaylanmış kaydı veya doğrulanmış webhook'u bekleyin.

Webhook işleyicilerini yinelenmeye dayanıklı tasarlamamak

Webhook tekrar denemeleri olağandır. Yinelenen bir olayın ürünü iki kez vermesini veya erişimi iki kez uzatmasını engellemek için benzersizlik kuralı uygulayın.

Başlangıçta çok fazla varlığı etkinleştirmek

Her ek token; fiyatlandırma, sözleşme, likidite, müşteri desteği, mutabakat ve iade işlerini artırır. Müşterilerin gerçekten talep ettiği rotayla başlayın.

Hazine yönetimini ve iadeleri göz ardı etmek

Tahsilat, sürecin yalnızca yarısıdır. Hacim artmadan önce imza denetimlerini, gas bulunabilirliğini, mutabakatı, değerlemeyi ve giden iadeleri test edin.

Sıkça Sorulan Sorular

Base üzerinden USDC ödemelerini nasıl kabul edebilirim?

Önce Base üzerinde USDC seçeneğinin kimlik doğrulamalı işletme ayarlarınızda yer aldığını teyit edin. Kontrollü bir Base tahsilat cüzdanı yapılandırın, desteklenen USDC sözleşmesini doğrulayın ve ardından ödeme linki veya entegre ödeme sayfası oluşturun. Kesin tutarı ve ağı gösterin; ürünü yalnızca eşleşen onaylı ödeme veya doğrulanmış webhook sonrasında teslim edin.

Base ana ağının zincir kimliği nedir?

Base ana ağı 8453 zincir kimliğini kullanır. Resmî Base belgelerinde gas para birimi ETH, blok gezgini ise BaseScan olarak belirtilir. Zincir kimliğini cüzdan ve entegrasyon yapılandırmasını doğrulamak için kullanın; müşteriye yönelik açık ağ etiketlerinin yerine kullanmayın.

Müşterilerin Base üzerinde USDC ile ödeme yapmak için ETH'ye ihtiyacı var mı?

Evet. Base üzerindeki sıradan bir USDC token aktarımında gönderici cüzdanın gas ücretini Base üzerindeki ETH ile ödemesi gerekir. ETH gas ücreti, USDC cinsinden satın alma tutarından ayrıdır.

Base üzerindeki yerel USDC sözleşmesi nedir?

Circle'ın sözleşme dizininde Base üzerindeki yerel USDC adresi 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 olarak listelenir. Bir cüzdan aramasından veya doğrulanmamış token listesinden sözleşme kopyalamak yerine ihraççının güncel dizinini ve kimlik doğrulamalı ödeme ayarlarınızı yeniden kontrol edin.

Base üzerindeki herhangi bir token'ı kabul edebilir miyim?

Böyle bir varsayım güvenli değildir. Yalnızca etkin ayarlarınızda sunulan ve tahsilat, fiyatlandırma, onay, muhasebe ve iade süreçlerinizin desteklediği kesin token ve Base birleşimlerini kabul edin.

Base ödemeleri anında ve kesin midir?

Bunun sözünü vermeyin. Gönderilmiş bir işlem beklemede kalabilir veya başarısız olabilir; işletmenin yine de bir onay politikasına ihtiyacı vardır. Ödeme akışındaki onaylanmış durumu ve siparişe uygun risk denetimlerini kullanın.

Ödeme linki mi yoksa entegre ödeme sayfası mı kullanmalıyım?

Dar kapsamlı bir pilot uygulama, faturalar veya elle teslim edilen hizmetler için ödeme linkleriyle başlayın. Onayın bir hesabı, siparişi, lisansı, kredi bakiyesini veya erişim süresini otomatik olarak güncellemesi gerektiğinde entegre ödeme sayfası kullanın.

Base ödemesi iade edilebilir mi?

İşletme, iade politikası kapsamında ayrı bir giden işlem gönderebilir. Asıl ödemeyi, müşteriyi, hedefi, varlığı, tutarı, onayı ve ücret uygulamasını doğrulayın; ardından iade işlemini ayrı olarak kaydedin.

Sonuç

Base üzerinden kripto kabul etmek, ödeme sayfasına cüzdan adresi yapıştırmak yerine kontrollü bir ödeme süreci olarak ele alındığında en iyi sonucu verir. Müşterilerin zaten elinde tuttuğu tek bir token ile başlayın; dolar cinsinden fiyatlandırılmış ürünlerde bu çoğu zaman USDC'dir. Ardından kimlik doğrulamalı ayarlarda ilgili Base rotasının gerçekten bulunduğunu teyit edin.

Zincir kimliği 8453 değerini, tahsilat adresini, desteklenen token sözleşmesini ve müşterinin ETH gas ihtiyacını doğrulayın. Düşük tutarlı bir işlemle beklemedeki ve onaylanmış durumları, webhook tekrar denemelerini, yinelenmeye dayanıklı teslimatı, mutabakatı ve iadeleri test edin. Bu rota güvenilir biçimde çalıştıktan sonra yalnızca müşteri talebi ek operasyon işlerini haklı çıkarıyorsa entegre ödeme sayfasına, tekrarlayan erişime veya başka bir token'a geçin.

İşletmeniz için kripto ödemelerini kabul etmeye başlayın şimdi

Geliri maksimize edin, maliyetleri minimize edin.