Checkout UI extensions mı, Shopify Functions mı?

İkisi de ödeme sayfası (checkout) genişletilebilirliğinin parçası ve ikisi de genellikle bir uygulamanın içinde gelir; bu yüzden sık karıştırılır. Fark basit: Checkout UI extension müşterinin gördüğünü değiştirir; Shopify Function ise ödeme sayfasının ne yaptığını değiştirir. Teslimat tarihi seçici bir arayüzdür. Belirli bir tutarın üzerindeki siparişlerde kapıda ödemeyi gizlemek ise mantıktır. Gerçek gereksinimlerin çoğu ikisinden de birer tane ister.

Yan yana

Bir kuralı uygulamak: arayüzü değil, Function’ı kullanın

Yakın zamana kadar bir Checkout UI extension, block_progress yetkisini tanımlayıp useBuyerJourneyIntercept çağırarak müşterinin bir sonraki adıma geçmesini durdurabiliyordu. Shopify ikisini de API sürümü 2026-07’den itibaren kullanımdan kaldırdı (değişiklik günlüğü, 2 Temmuz 2026) ve gelecekteki bir sürümde tamamen çıkarılacaklarını söylüyor.

Shopify’ın gösterdiği geçiş yolu net. Bir iş kuralını uygulamak için Cart and Checkout Validation Function kullanın; bu Function sunucu tarafında çalışır ve kuralı hızlı ödeme cüzdanları ile agentic checkout dahil tüm ödeme yüzeylerinde tutarlı biçimde uygular. Bir indirim kodunu özel bir mesajla reddetmek için Discount Function API’yi kullanın. Eski intercept ayrıca mağaza sahibinin extension’a bu yetkiyi vermesine bağlıydı ve arayüzde çalışıyordu; bir doğrulama Function’ı ise etkin olduğu sürece Shopify’ın sunucularında uygulanır. Bkz. ödeme sayfası doğrulamasının neleri engelleyebildiği.

Mevcut bir uygulama ödemeyi bir extension’dan engelliyorsa, doğrulama Function’ına geçişini API kaldırıldığında değil, şimdiden planlayın.

Bir intercept’i doğrulama Function’ına taşımak genellikle kolaydır; çünkü kural aynı kalır, yalnızca yeri değişir:

1. Intercept’in kontrol ettiği her koşulu ve gösterdiği mesajı yazın.
2. Her koşulun arkasındaki verinin doğrulama Function’ının girdi sorgusunda bulunduğunu doğrulayın: sepet satırları, varyant, müşteri ya da mağaza metafield’ları (meta alanları) veya doğrulamanın kendi ayarları.
3. Function’ı aynı mesajları döndürecek şekilde kurun; mümkünse ilgili alanı, değilse tüm sepeti hedefleyin.
4. Extension’ı, kuralı müşteri ona takılmadan önce açıklamak gibi görsel işler için tutun ve block_progress yetkisini ondan kaldırın.

Plan sınırları farklı yerlerde

İki araç farklı yerlerden sınırlanır; bu da Plus altındaki bir mağazanın neler yapabileceğini değiştirir:

• UI extension’lar, nerede göründüklerine göre sınırlanır. Bilgi, kargo ve ödeme adımlarındaki extension’lar Plus gerektirir. Teşekkürler ve Sipariş durumu sayfalarında ve müşteri hesabı sayfalarında, UI extension içeren uygulamalar Basic ve üzerinde çalışır.
• Function’lar, nasıl dağıtıldıklarına göre sınırlanır. Her plandaki mağaza Function içeren App Store uygulamalarını kullanabilir; Function içeren özel uygulamaları ise yalnızca Plus mağazaları kullanabilir. Ödeme koşulları gibi birkaç özellik her durumda Plus gerektirir.

Pratikte Plus olmayan bir mağaza, sepeti doğrulayan ya da bir ödeme yöntemini gizleyen bir App Store uygulaması kullanabilir; ama hiçbir uygulamayla kargo adımına özel bir alan ekleyemez.

İkisine birden ihtiyaç duyduğunuzda

Pek çok gereksinim ikisini birleştirir. Extension bilgiyi toplar ya da açıklar; Function karar verir. Tipik ikililer:

• Bir extension müşterinin vermesi gereken bilgiyi toplar; zorunlu değer eksik ya da geçersizse bir doğrulama Function’ı ödemeyi engeller.
• Bir Function belirli sepetlerde bir ödeme yöntemini gizler; bir extension da müşteri tahmin etmek zorunda kalmasın diye nedenini açıklar.
• Bir indirim Function’ı kademeli fiyat uygular; bir extension sepetin bir sonraki kademeye ne kadar uzak olduğunu gösterir.

Pratik kural: bir şeyi uygulatmak için asla arayüze güvenmeyin. Bir siparişin geçmemesi gerekiyorsa onu durduran Function’dır; extension ise nedenini anlaşılır kılmak için oradadır.

Sık gereksinimler ve karşılıkları

Seçim yapmadan önce bilmeye değer iki operasyonel sınır var. Discount, Delivery Customization, Payment Customization ve Cart and Checkout Validation dahil çoğu Function API’sinde bir mağaza, tüm uygulamaları genelinde her türden en fazla 25 function etkinleştirebilir. Arayüz tarafında ise ödeme sayfası düzenleyicisindeki tek bir blok konumu en fazla üç extension alır. Çok sayıda ödeme sayfası uygulaması olan mağazalar bu sınırlardan birine ulaşabilir.

Function’lar ayrıca sabit kaynak sınırlarıyla çalışır: 256 kB derlenmiş binary, 10.000 kB doğrusal bellek ve 200 satıra kadar sepetlerde 11 milyon komut, 128 kB girdi ve 20 kB çıktı. Büyük arama tabloları gerektiren bir kuralın bu sınırlara sığması gerekir; verisini kod yerine metafield’larda tutmanın bir nedeni de budur.

Adım adım seçim

1. Değişikliği tek bir cümleyle anlatın. Cümle “göster”, “sor” ya da “bildir” diye başlıyorsa arayüzdür. “Ücretlendir”, “gizle”, “yeniden sırala” ya da “engelle” diye başlıyorsa mantıktır.
2. Arayüz için: hangi ödeme adımına ait olduğunu kontrol edin. Bilgi, kargo ya da ödeme adımı Plus demektir.
3. Mantık için: ilgili Function API’sini (Discount, Delivery Customization, Payment Customization, Cart and Checkout Validation, Cart Transform) bulun ve bir App Store uygulamasının bunu zaten sunup sunmadığına bakın.
4. Mantığın mutlaka uygulanması gerekiyorsa, işin içinde bir extension olsa bile onu bir Function’a koyun.
5. Canlı mağazaya kurmadan önce ikisini de gerçekçi sepetlerle bir geliştirme mağazasında kurup test edin.

Lintel’in rolü

Lintel iki yarıyı da kurar: mantık için Shopify Functions, arayüz için bir özel uygulama içinde Checkout UI extensions; hepsi planınızın izin verdiği kapsamda. Extension’larınızdan biri ödemeyi hâlâ kullanımdan kaldırılmış intercept ile engelliyorsa, o kuralı bir doğrulama Function’ına taşımak sınırları net bir iştir.