Yerel ödemeye genel bakış

Kullanıcıların ödeme yapabilmesi için doğrudan ödeme entegrasyonunu uygulamanız gerekir. Bu, Google'ın ödeme adımlarını sunucularınızla programlı olarak yönetmesine olanak tanıyan standart bir REST API oluşturmayı içerir. Bu yöntem, kullanıcılar için en sorunsuz deneyimi sağlar. Google, ilk olarak alıcı için kullanıcı arayüzünü oluşturacak ve gelecekte daha fazla etkileşimli deneyimi desteklemeyi planlıyor.

Ödeme adımları

Yerel entegrasyon, Google'ın ödeme oturumları oluşturmak ve yönetmek için çağırabileceği bir RESTful API oluşturmanızı gerektirir.

Genel akış şu şekildedir:

  1. Ödeme oturumu oluşturma: Kullanıcı ve isteğe bağlı olarak bir temsilci, oturuma öğe ekleme döngüsündedir.
  2. Google kullanıcı arayüzüne devretme: Kullanıcı, ödeme yapmaya karar verdiğinde (etkileşimde bulunulduysa) kontrolü bir Google kullanıcı arayüzüne devreder (ödeme oturumu verilerini ileterek).
  3. Manuel ödeme: Kullanıcı artık hassas sipariş karşılama ve ödeme ayrıntılarını doldurup siparişi göndermek için yalnızca Google kullanıcı arayüzüyle etkileşimde bulunur. Ajan bu kısma dahil değildir ve determinizm sağlanır.
  4. Tamamlama ve geri dönüş: Google kullanıcı arayüzünde, siparişi onaylamak için "Teşekkür ederiz" sayfası gösterilir. İsteğe bağlı olarak kullanıcı, tamamlanan satın alma işlemi hakkında bildirim almış olabilecek aracıya geri yönlendirilebilir.

Ödeme oturumu durumu yaşam döngüsü

Kullanıcı ödeme adımlarında ilerledikçe ödeme oturumunu status mevcut durumu yansıtacak şekilde güncellemeniz gerekir. Oturum aşağıdaki yaşam döngüsünden geçer:

  • incomplete: Oturum oluşturulduğundaki ilk durum. Bu, zorunlu bilgilerin (ör. kargo yöntemleri, vergiler veya kullanıcı ayrıntıları) eksik olduğunu ya da hesaplanmadığını gösterir.
  • ready_for_payment: Kullanıcı kargo adresini güncelledikten ve siz kargo seçeneklerini ve toplamları hesapladıktan sonra ancak ödeme aracı kesinleştirilmeden önce kullanılacak durum.
  • ready_for_complete: Ödeme aracı seçildikten ve tüm sipariş ayrıntıları doğrulandıktan sonra tam ödeme nesnesi hydration işlemi sırasında kullanılacak durum.
  • completed: Ödeme işlemini başarıyla gerçekleştirip siparişi verdikten sonra döndürülen nihai durum.
  • canceled: Ödeme oturumu iptal edilirse döndürülen durum.
  • error: Kurtarılamayan bir işletme mantığı hatası ödeme işlemini engellediğinde döndürülen durum. Bu durum, UCP'nin 2026-04-08 ve sonraki sürümlerinde kullanılabilir.

Çok Öğeli Ödeme Adımları:

Google artık tek bir ödeme oturumunda birden fazla farklı satır öğesini destekliyor. Genel akış şu şekildedir:

  1. Kullanıcı, UCP'nin etkin olduğu bir arayüzden ödeme işlemini başlatır (ör. bir üründe "Hemen satın al"ı tıklayarak).
  2. POST /checkout-sessions dizisindeki tüm farklı öğeler dahil olmak üzere line_items çağrısı yapılır. line_items dizisi, ödeme işlemi yapılan her benzersiz öğe için ayrı bir nesne içerir.
  3. Kullanıcı, PUT /checkout-sessions/{id} çağrılarını kullanarak ödeme aracını, sipariş karşılama ayrıntılarını güncelleyebilir veya indirim uygulayabilir.
  4. Kullanıcı "GPay ile öde" düğmesini tıkladığında POST /checkout-sessions/{id}/complete çağrısı yapılır.

Kimlik doğrulama

API anahtarları ve OAuth 2.0 gibi desteklenen kimlik doğrulama yöntemleri de dahil olmak üzere Native Checkout API uç noktalarınızın güvenliğini sağlama hakkında ayrıntılı bilgi için Kimlik Doğrulama ve Güvenlik kılavuzuna bakın.

Geliştirici araçları

Ödeme sayfasına doğrudan yönlendirme API'sini uygulamanıza yardımcı olması için Evrensel Ticaret Protokolü GitHub deposunda aşağıdaki kaynakları bulabilirsiniz:

  • UCP GitHub deposu: Kapsamlı dokümanlar, özellikler ve topluluk kaynakları için ana depoyu inceleyin.
  • SDK'lar: Entegrasyonunuzu hızlandırmak için yazılım geliştirme kitlerini kullanın. Aşağıdakiler de dahil olmak üzere dile özgü SDK'lar mevcuttur:

  • Uygunluk testleri: Uygunluk testi paketi'ni kullanarak API uç noktalarınızı UCP spesifikasyonuna göre doğrulayın.

    Bu sayede uygulamanızın gerekli standartları ve davranışları karşılaması sağlanır.

Geliştirme ve test sürecinizi kolaylaştırmak için bu araçları kullanmanızı önemle tavsiye ederiz.

Hizmet düzeyi hedefleri

Aşağıdaki hizmet düzeyi hedefleri (SLO'lar), Native Checkout REST API uç noktaları için geçerlidir. Google ile entegrasyon yapan işletmelerin, API performansı ve kullanılabilirliği için bu hedefleri karşılaması beklenir.

Uç nokta Kullanılabilirlik Gecikme (50. yüzdelik dilim) Gecikme (95. yüzdelik dilim)
POST /checkout-sessions (Oluştur) >= %95 <= 1 saniye <= 4 saniye
PUT /checkout-sessions/{id} (Güncelle) >= %95 <= 1 saniye <= 5 saniye
POST /checkout-sessions/{id}/complete (Tamamlandı) >= %95 <= 6 saniye <= 10 saniye

Gecikme süresinin 50. yüzdelik dilimi, isteklerin en az% 50'sinin bu süre içinde tamamlanmasının beklendiğini gösterir. Gecikmenin 95. yüzdelik dilimi, isteklerin en az% 95'inin bu süre içinde tamamlanmasının beklendiğini gösterir.

Sonraki adımlar

UCP sürümünüz için ödeme API'si yüklerini ve teknik uygulama ayrıntılarını görüntüleyin:

Üçüncü taraf servis sağlayıcı olarak entegrasyon yapıyorsanız satıcı profillerini barındırmak ve hesap ilişkisi el sıkışmalarını yapılandırmak için UCP Checkout hizmeti kurulumu bölümüne gidin.

Önceki
Sipariş yaşam döngüsü (satın alma sonrası)
Sonraki
Hata kodları