Salesforce B2C Commerce'te (SFCC) yerleşik bir abonelik motoru yoktur. Business Manager'da "abone ol ve kazan" diye açabileceğiniz bir ayar bulunmaz. Abonelikler, Salesforce'un pazar yerindeki bir partner cartridge'ı ile eklenir ya da platformun API'leri üzerine kurulur. Salesforce'un kendi abonelik özelliği olan Commerce Subscriptions ise farklı bir ürüne, B2B Commerce ve D2C Commerce'e aittir ve dijital ürünlerle sınırlıdır.

Bu rehber, abonelikleri nasıl ekleyeceklerine karar veren mimarlar içindir: partner cartridge'lar, SCAPI ile yenileme siparişleri, ödeme tokenizasyonu, abone ol ve kazan (subscribe-and-save) fiyatlandırması, SFRA ve PWA Kit'te self-servis ve Shopify Plus karşılaştırması. Platformun geneli için SFCC rehberine bakın.

SFCC abonelikleri yerleşik olarak destekliyor mu?

Açıp kullanabileceğiniz bir özellik olarak hayır. Bunu üç şey netleştiriyor:

Salesforce'un yerleşik abonelik özelliği başka bir ürünü hedefliyor. Commerce Subscriptions'ı genel kullanıma açan sürüm notu, kapsamı Salesforce Pricing'in etkin olduğu B2B Commerce, D2C Commerce ve Revenue Cloud ile sınırlar. Salesforce Payments gerektirir ve Commerce lisansına dahil değildir. Kurulum makalesi de şunu ekler: "Fiziksel ürünler için abonelik oluşturamazsınız."
B2C Commerce bir abonelik modeli değil, yapı taşları dokümante eder. Script API ve SCAPI; sepetleri, siparişleri, tokenize payment instrument'lar içeren müşteri wallet'larını, promosyonları ve job'ları kapsar. Bu rehber için kullanılan B2C Commerce referanslarının hiçbiri bir abonelik nesnesi, faturalama takvimi ya da yenileme süreci tanımlamaz.
Salesforce'un kendi paket teklifi bile abonelik için bir partner kullanır. B2C Commerce Consumer Goods çözüm rehberi, kullanım senaryoları arasında bir abonelik teklifini sayar ve Quick Start Commerce for Subscriptions veri sayfasına bağlantı verir. Bu paket B2C Commerce ve Salesforce Order Management'ı, abonelik yeteneği için Ordergroove Essentials ile birleştirir; kurulumu SI partnerleri yapar. AgentExchange (eski adıyla AppExchange) başka abonelik cartridge'ları da listeler; aşağıda ele alınıyorlar.

Karışıklığın çoğu ürün adlarından kaynaklanır, bu yüzden net olun:

Ürün	Diğer adları	Abonelik nasıl çalışır
B2C Commerce	SFCC, Commerce Cloud, eski adıyla Demandware	Partner cartridge ya da özel geliştirme
B2B Commerce ve D2C Commerce	Bir Salesforce org'undaki Commerce mağazaları (Lightning Experience)	Commerce Subscriptions: dijital ürünler, Salesforce Pricing ve Salesforce Payments, ayrı lisans

B2C Commerce kullanıyorsanız "D2C abonelikleri" hakkındaki bir duyuru sizin storefront'unuz için geçerli değildir.

Bir abonelik altyapısının yapması gerekenler

Aşağıdaki her seçenek, aynı sorumlulukların farklı bir paylaşımıdır:

Yetenek	Neyi kapsar	Genellikle kimde
Kayıt (enrolment)	PDP'de ya da sepette abonelik seçeneği ve aralığı	Storefront ve cartridge
Abonelik kaydı	Ürünler, aralık, sonraki tarih, adres, ödeme referansı, durum	Abonelik platformu ya da custom object'ler
Ödeme token'ı	Ödeme yöntemine, onayla saklanan yeniden kullanılabilir bir referans	PSP vault'u
Yenileme siparişi	Her dönemde fiyatı ve vergisi hesaplanmış gerçek bir B2C Commerce siparişi	Shopper API'leri, Orders API ya da bir job
Yenileme tahsilatı	Token'a karşı üye işyeri tarafından başlatılan (merchant-initiated) provizyon	PSP, tek bir sistemin tetiklemesiyle
Tahsilat takibi (dunning)	Yeniden denemeler, kart güncellemeleri, bildirimler	Abonelik platformu
Self-servis	Atlama, duraklatma, ürün değiştirme, tarih, adres ya da kart değişikliği; iptal	My Account sayfaları ya da tedarikçi widget'ları
Fiyatlandırma	Abone ol ve kazan indirimleri, ilk sipariş teklifleri	Promosyonlar, custom price adjustment ya da tedarikçi
Fulfilment	Export, OMS, kargo, iadeler	Mevcut sipariş akışı

Geri kalan her şeyi tek bir karar belirler: abonelik nerede yaşıyor ve yenileme tahsilatını hangi sistem yapıyor? Bu soruyu açık bırakırsanız iki sistem de kartın sahibi olduğunu düşünmeye başlar.

1. seçenek: partner abonelik cartridge'ı

Aşağıdaki AgentExchange listelerinin çözüm türü B2C Commerce Cartridge'dır. Alfabetik sıradadırlar, bir sıralama değildir; özellikler değiştiği için güncel listeyi kontrol edin:

Litmus7 Subscriptions Cartridge for B2C Commerce: atlama, duraklatma, iptal, adres ve ödeme değişiklikleri ile müşteri hizmetleri için raporlu bir Business Manager eklentisi. Liste, cartridge'ı tamamen yerleşik B2C Commerce işlevleriyle geliştirilmiş olarak tanımlar.
Ordergroove Subscriptions: harici bir abonelik platformu. Yinelenen sipariş yerleştirme dokümantasyonu bir push modeli anlatır: vadesi gelen her sipariş, üye işyerinin açtığı bir HTTPS endpoint'ine ya da SFTP üzerinden bir toplu dosyaya gider; başarısız bir yerleştirme bir sonraki yerleştirme zamanında yeniden denenir.
Smart Order Refill by OSF Digital: Business Manager'da yapılandırılan aralıklar, tekrar alım indirimleri, ürün bazında müşteri grubu erişimi ve düzenleme, duraklatma ve iptal için My Account altında bir panel.
sticky.io Subscriptions Cartridge for B2C Commerce: Business Manager'dan yönetilen abonelikler, bir müşteri portalı, süresi dolan kartlar için otomatik güncelleme ve başarısız yenilemelerde yeniden deneme.

Bu listenin dışında iki kaynak daha var. Subscribe Pro, resmi SFCC cartridge'ını GitHub'da yayımlar. Bazı ödeme cartridge'ları da aboneliği paketle birlikte sunar: Klarna'nın SFCC dokümantasyonu, vadesi gelen abonelikleri işleyen bir back-end job ve müşteri profilinde saklanan bir Klarna customer token'ı anlatır. Yalnızca SFRA'yı dokümante eder, abonelikli checkout'u yalnızca giriş yapmış müşterilere açar ve standart ürünlerle abonelik ürünlerinin aynı sepette karışmasını kısıtlar.

Listelerin arkasındaki iki mimari

Her tedarikçinin dokümantasyonunda önce tek bir sorunun cevabını arayın: aboneliğin ana kayıt sistemi (system of record) nerede?

	Platform içi cartridge	Harici abonelik platformu
Abonelik verisi	B2C Commerce: custom object'ler, profil attribute'ları	Tedarikçinin platformu
Yenileme tetikleyicisi	Zamanlanmış bir B2C Commerce job'ı	B2C Commerce'e sipariş gönderen tedarikçi zamanlayıcısı
Yenileme tahsilatı	B2C Commerce'ten çağrılan PSP cartridge'ınız	Tedarikçinin PSP entegrasyonu ya da onunla paylaştığınız bir token
Tahsilat takibi, kart güncelleme, analitik	Cartridge ne implemente ettiyse o	Genellikle tedarikçinin ana ürünü
Başlıca riskler	Job süresi ve nesne kotaları; kodunu siz devralırsınız	Uzlaştırılacak iki veri deposu; izlenecek bir sistem daha

Genel olarak biri diğerinden üstün değildir: platform içi çözüm ikinci bir sistem eklemez; harici platform ise tahsilat takibi ve elde tutma araçları getirir ama işletmeniz gereken bir entegrasyon ekler.

Her tedarikçiye sorulacak sorular

Hangi storefront'lar destekleniyor: SFRA, SiteGenesis, PWA Kit ya da SCAPI üzerinde headless bir istemci?
Yenileme siparişi nasıl oluşturuluyor: OCAPI, SCAPI, bir controller endpoint'i ya da sipariş içe aktarma? OCAPI deprecated durumda; bkz. SCAPI vs OCAPI.
Hangi PSP'ler merchant-initiated yenilemeleri destekliyor ve token'ı kim saklıyor?
Yenileme dw.order.calculate üzerinden geçiyor mu, yani promosyon, vergi ve kargo kurallarınız uygulanıyor mu?
Birden çok site, para birimi ve dil nasıl yönetiliyor; stok ya da ödeme başarısız olunca ne oluyor?

2. seçenek: B2C Commerce API'leri üzerine kendiniz kurun

Abonelik modeliniz alışılmadıksa, zaten bir faturalama platformunuz varsa ya da hiçbir cartridge storefront'unuza uymuyorsa kendiniz kurun. Bu durumda abonelik kaydı, zamanlayıcı, yenileme siparişinin oluşturulması ve yenileme tahsilatı sizindir. Headless bir yapıda kayıt ve zamanlayıcı genellikle B2C Commerce'in dışında yaşar; custom object'lerde tutacaksanız önce güncel nesne kotalarını kontrol edin.

Shopper API'leri ile yenileme siparişleri

Harici bir zamanlayıcı için en temiz yol, her yenilemeyi bir shopper'ın yapacağı gibi yerleştirmektir; böylece B2C Commerce siparişin fiyatını, promosyonlarını, vergisini ve doğrulamasını kendisi yapar. SLAS bunun için gereken login'i sağlar: Trusted System on Behalf (TSOB), back office iş akışlarında sistemden sisteme iletişim için tasarlanmış bir login akışıdır ve bir sistemin shopper adına işlem yapmasını da kapsar. sfcc.ts_ext_on_behalf_of scope'una sahip bir SLAS private client gerektirir. Build Baskets and Place Orders rehberi ardından tek istekte oluşturulan ve Shopper Orders'a gönderilen bir sepet gösterir:

#!/bin/bash
set -euo pipefail

# Yalnızca sunucu tarafında: SLAS private client secret asla tarayıcıya ulaşmamalı
CODE='<short code>'
ORG='<organization id>'
SITE='<site id>'
CLIENT='<SLAS private client id>'
SECRET='<SLAS private client secret>'
LOGIN='subscriber@example.com'   # abonenin B2C Commerce login'i

BASE="https://$CODE.api.commercecloud.salesforce.com"

# 1. Kayıtlı bir B2C Commerce shopper'ı için TSOB token'ı
TOKEN=$(
  curl "$BASE/shopper/auth/v1/organizations/$ORG/oauth2/trusted-system/token" \
    -sS --fail-with-body \
    -u "$CLIENT:$SECRET" \
    -d 'hint=ts_ext_on_behalf_of' \
    -d 'grant_type=client_credentials' \
    -d "channel_id=$SITE" \
    -d 'idp_origin=ecom' \
    --data-urlencode "login_id=$LOGIN" | jq -r '.access_token'
)

# 2. Yenileme sepetini tek istekte oluşturun. c_subscriptionInterval için
#    ProductLineItem'da bir custom attribute gerekir; payment instrument, saklanan
#    PSP token'ını ödeme cartridge'ınızın beklediği biçimde taşımalı.
BASKET=$(
  curl "$BASE/checkout/shopper-baskets/v1/organizations/$ORG/baskets?siteId=$SITE" \
    -sS --fail-with-body \
    -H "Authorization: Bearer $TOKEN" \
    -H 'Content-Type: application/json' \
    -d '{
          "productItems": [
            { "productId": "<sku>", "quantity": 1, "c_subscriptionInterval": "monthly" }
          ],
          "customerInfo": { "email": "subscriber@example.com" },
          "shipments": [{
            "shipmentId": "me",
            "shippingAddress": { "firstName": "Joe", "lastName": "Shopper",
              "address1": "415 Mission St.", "city": "San Francisco",
              "postalCode": "94105", "stateCode": "CA", "countryCode": "US" },
            "shippingMethod": { "id": "<shipping method id>" }
          }],
          "billingAddress": { "firstName": "Joe", "lastName": "Shopper",
            "address1": "415 Mission St.", "city": "San Francisco",
            "postalCode": "94105", "stateCode": "CA", "countryCode": "US" },
          "paymentInstruments": [{ "paymentMethodId": "<payment method id>" }]
        }' | jq -r '.basketId'
)

# 3. Sepeti sipariş olarak gönderin
curl "$BASE/checkout/shopper-orders/v1/organizations/$ORG/orders?siteId=$SITE" \
  -sS --fail-with-body \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{ "basketId": "'"$BASKET"'" }'

Toplu yenileme için önemli kısıtlar:

Salesforce, TSOB'nin OAuth ve OIDC standardının dışında kaldığı için shopper kimlik doğrulama akışlarında tercih edilen yöntem olmadığını belirtir. Onu sunucu tarafında, bunun gibi sistem iş akışları için kullanın.
Aynı shopper için 3 saniyelik servis penceresi içinde tekrarlanan login'ler HTTP 409 döndürür; bu yüzden bir abonenin yenilemelerini bir arada işleyin.
Her zaman aynı login_id değerini gönderin; farklı bir değer yeni bir shopper kaydı oluşturur. Rehber ayrıca shopper bilgileri sık değişiyorsa ve idp_origin=ecom ise TSOB kullanılmamasını önerir, çünkü TSOB B2C Commerce'teki en güncel müşteri bilgisini almaz.
26.6 sürümünden itibaren bir TSOB login'i profildeki son giriş zamanını günceller; yani son giriş artık "shopper siteye geldi" anlamına gelmez.
API hook çalıştırma etkinse (bir Business Manager feature switch'i), dw.order.calculate dahil sepet ve sipariş hook'ları çalışır. Bu switch ve extension'larınızın ve varsayılan mantığın çalışıp çalışmayacağını belirleyen dönüş değeri kuralları için SFCC hook rehberine bakın.
Checkout rehberi, ödemeyi doğrulamadan önce siparişi oluşturmayı önerir. Tahsilatı sonradan başarısız olan bir yenileme siparişinin yolunu tasarlayın ve o aboneliği tahsilat takibine devredin.

Orders API ile fiyatı hesaplanmış siparişler

Abonelik platformu yenilemenin fiyatını ve tahsilatını kendisi yapıyorsa, Orders API createOrders endpoint'i üçüncü taraf bir sistemden sipariş oluşturur. Ön koşul katıdır: dokümantasyona göre önce checkout sürecini tamamlamanız, yani tüm tutarlılık kontrollerini uygulamanız, stoğu rezerve etmeniz, ödemeye provizyon almanız, promosyonları uygulamanız ve siparişin tam maliyetini hesaplamanız gerekir. Karşılığında bu siparişler, durum güncellemeleri ve export'lar dahil, doğrudan B2C Commerce platformunda oluşturulan siparişlerle aynı şekilde işlenir. Bunu yalnızca harici platform fiyatlandırmanın, stoğun ve ödemenin gerçekten sahibiyse seçin; aksi halde checkout'u başka bir yerde yeniden yazıyorsunuz demektir.

Siparişi yerleştirmek ve fulfilment'a devretmek

Yenilemeler, storefront siparişleriyle aynı akıştan geçmelidir. SOM entegrasyon rehberine göre B2C Commerce, Salesforce Order Management'a (SOM) bağlandıktan sonra OrderMgr.placeOrder(order) siparişi SOM'da oluşturur; PWA Kit 3.19'dan itibaren kayıtlı shopper'lar SOM siparişlerini storefront'ta takip edebilir, iptal edebilir ve iade edebilir. OMS, finans ve müşteri hizmetleri ayırt edebilsin diye yenileme siparişlerini bir custom attribute ile işaretleyin.

Ödemeler: kart değil, token

Salesforce'un SCAPI checkout rehberi açıktır: "Ödeme kartı verisini asla B2C Commerce'e göndermeyin." Shopper kart bilgisini PSP'nin kendi script'ine ya da iframe'ine girer, B2C Commerce ise bir token alır.

Script API bu modeli destekler. PaymentInstrument.setCreditCardToken(), bir tokenizasyon sağlayıcısından gelen token'ı saklar; token set edildiğinde hesap bilgileri maskelenir ve kart attribute'ları dondurulur. Kayıtlı müşteriler kayıtlı instrument'larını wallet'larında (dw.customer.Wallet) tutar ve SFRA'nın kayıtlı kullanıcı checkout'u bunları kullanabilir.

Değişen şey, her PSP cartridge'ının merchant-initiated yenilemeleri nasıl ele aldığıdır:

Adyen, düzenli aralıklarla başlatılan abonelikleri sabit bir takvime bağlı olmayan ödemelerden ayırır ve her token'ı her shopper için benzersiz bir shopper reference'a bağlar. SFCC eklentisinin özellik tablosu, yinelenen ödemeleri SFRA için tek seferlik ve sabit olmayan takvimli, Composable Storefront için tek seferlik olarak listeler. Sabit takvimli bir abonelik akışını varsaymak yerine Adyen'le ya da tedarikçinizle teyit edin.
Stripe'ın SFCC cartridge kullanım rehberi, giriş yapmış müşterilerin checkout'ta Stripe'ta kayıtlı ödeme kaynaklarından seçim yaptığını ve profilde bir Stripe Customer ID (stripeCustomerID) saklandığını gösterir. Off-session yenileme tahsilatını kendi sürümünüz için ayrıca teyit edin.
Klarna, yinelenen ödemeler için bir customer token'ını profilde saklar ve her yenilemede bu token'dan tahsilat yapar.

PSP hangisi olursa olsun üç kural geçerlidir:

Yenilemeleri tek bir sistem tahsil eder. Merchant-initiated tahsilatı ya abonelik platformu ya da B2C Commerce tetikler, asla ikisi birden değil.
Onay kayıt anında alınır. Shopper saklanan ödeme bilgisine ve takvime onay verir; bu onayı abonelikle birlikte saklayın.
Kart güncelleme bir alan değil, bir akıştır. SFRA özellik listesi, My Account'ta ödeme yöntemlerinin görüntülenip eklenip silinebildiğini, mevcut bir yöntemin düzenlenmesinin ise desteklenmediğini belirtir. Bu yüzden "kartı güncelle" işlemi "yeni bir instrument ekle, sonra aboneliği ona yönlendir" demektir.

Abone ol ve kazan fiyatlandırması

Bir abonelik satırını fiyatlandırmanın üç yolu vardır:

Fiyatı tedarikçi belirlesin: fiyatlandırmanın sahibi oysa ve fiyatı hesaplanmış siparişler oluşturuyorsa.
Promosyon motorunu kullanın: indirim, motorun koşullarına uyuyorsa. PromotionMgr referansı, aktif promosyonları müşteri grupları, source code ve sepetteki kuponlar üzerinden tanımlar; dolayısıyla bir yenileme süreci her yenileme sepetine bir kupon ekleyebilir.
Custom price adjustment ekleyin: indirim tek bir satıra aitse; örneğin aynı sepette abonelikli ürüne %10 indirim, tek seferlik ürüne değil.

Custom adjustment dokümante edilmiş API'leri kullanır. ProductLineItem.createPriceAdjustment(promotionID, discount), satırın vergi sınıfı ve vergi oranıyla başlatılan bir düzeltme oluşturur. Promotion ID gerçek bir promosyonun ID'si olmamalıdır; PercentageDiscount da tam bu amaçla anında oluşturulabilir:

'use strict';

// cartridge/scripts/subscription/subscriptionDiscount.js
var PercentageDiscount = require('dw/campaign/PercentageDiscount');

// Business Manager'da tanımlı bir promosyonun ID'si OLMAMALI
var ADJUSTMENT_ID = 'SUBSCRIBE_AND_SAVE';

/**
 * Abonelik olarak işaretlenen her satıra yüzde indirimli bir düzeltme ekler.
 * dw.order.calculate implementasyonunuzdan, promosyonlar uygulandıktan
 * sonra ve vergi ile toplamlar hesaplanmadan önce çağırın.
 */
function applySubscriptionDiscount(lineItemCtnr, percentage) {
    var items = lineItemCtnr.getProductLineItems().iterator();
    while (items.hasNext()) {
        var pli = items.next();
        // Yeniden hesaplama sık çalışır: aynı promotion ID ile ikinci bir
        // düzeltme oluşturmak exception fırlatır, önce öncekini kaldırın
        var existing = pli.getPriceAdjustmentByPromotionID(ADJUSTMENT_ID);
        if (existing) {
            pli.removePriceAdjustment(existing);
        }
        // subscriptionInterval: ProductLineItem üzerinde tanımladığınız bir custom attribute
        if (pli.custom.subscriptionInterval) {
            pli.createPriceAdjustment(ADJUSTMENT_ID, new PercentageDiscount(percentage));
        }
    }
}

module.exports = { applySubscriptionDiscount: applySubscriptionDiscount };

API hook çalıştırma etkinse, Shopper Baskets ile oluşturulan yenileme sepetleri aynı hesaplama hook'unu çalıştırır; böylece kayıt fiyatı da her yenileme fiyatı da tek bir kuraldan gelir. Satır işareti, sepetteki ürün kalemine bir c_ property olarak gelebilir: SCAPI custom properties girdi dokümanlarında set edilebilir ve ProductItem desteklenen türlerden biridir.

SFRA ve PWA Kit'te müşteri self-servisi

Aboneyi elde tutmak hesap sayfasında kazanılır ya da kaybedilir ve iki storefront da hazır bir abonelik sayfasıyla gelmez:

SFRA'nın My Account bölümü paneli, profili, adres defterini, ödeme yöntemlerini ve sipariş geçmişini kapsar. Kendi controller ve template'lerinizle bir abonelik sayfası ekleyin ya da tedarikçinin widget'ını gömün.
PWA Kit'te sipariş geçmişi içeren hesap sayfaları ve 3.19'dan itibaren SOM sipariş işlemleri bulunur. Bir abonelik sayfasının veri kaynağına ihtiyacı vardır: tedarikçinin API'si ya da B2C Commerce'te tuttuğunuz veri üzerinde bir SCAPI custom API. Storefront seçiminin kendisi için SFRA vs PWA Kit yazısına bakın.

İptalleri ve destek taleplerini azaltan ayrıntılar:

Bir sonraki yenileme tutarını gösterin. Storefront kodunda BasketMgr.createTemporaryBasket(), mevcut oturumdaki müşteri için, shopper'ın açık storefront sepetine dokunmadan hesaplama yapmaya ya da sipariş oluşturmaya yönelik bir sepet oluşturur. Geçici sepetler 15 dakika sonra silinir ve varsayılan olarak bir müşterinin aynı anda en fazla 4 açık geçici sepeti olabilir.
İptalin yanında atlama, duraklatma ve tarih değiştirme sunun ve her yenilemeden önce hatırlatma gönderin.
İptal ve hatırlatma kurallarını sattığınız her pazar için hukuk ekibinizle kontrol edin.

Abonelikte SFCC ve Shopify Plus karşılaştırması

Shopify'da, Shopify Plus dahil, abonelikler uygulamaların üzerine kurulduğu bir platform modelidir ve selling plan'lar ile subscription contract'ları kullanır. Bir müşteri selling plan'ı olan bir ürünü satın aldığında Shopify bir subscription contract oluşturur; yenileme zamanında abonelik uygulaması bir billing attempt başlatır ve billing attempt bir sipariş oluşturur. Shopify ayrıca kendi Shopify Subscriptions uygulamasını yayımlar.

	B2C Commerce (SFCC)	Shopify, Plus dahil
Platformdaki abonelik modeli	Yok; cartridge ya da özel veri	Selling plan'lar ve subscription contract'lar
Checkout	Standart checkout; kaydı cartridge ekler	Yerleşik checkout contract'ı oluşturur
Yenileme siparişi	Shopper API'leri, Orders API ya da bir job	Uygulamanın başlattığı billing attempt siparişi oluşturur
Saklanan ödeme yöntemi	PSP vault'u; B2C Commerce'ten ya da tedarikçiden referanslanır	Shopify'ın sakladığı müşteri ödeme yöntemleri
Mantığın yeri	Cartridge'ınız, servisleriniz ya da tedarikçi	Shopify API'leri üzerindeki bir abonelik uygulaması

Shopify contract modelini kendisi tanımlar ve abonelik uygulamaları onun API'leri içinde çalışır; B2C Commerce ise modeli, dolayısıyla mimariyi size bırakır. Daha geniş karşılaştırma SFCC vs Shopify Plus yazısında.

Mimari karar tablosu

Durum	Önerilen yaklaşım	Neden
Standart aralıklarla fiziksel ürün yenileyen bir SFRA sitesi	Partner cartridge	Kayıt, hesap sayfaları ve yenilemeler paket halinde gelir
Öncelik elde tutma araçlarıysa (atlama, ürün değiştirme, geri kazanım, tahsilat takibi)	B2C Commerce cartridge'ı olan harici abonelik platformu	Elde tutma, tedarikçinin ana ürünüdür
Mevcut bir faturalama platformuyla headless storefront	Kendiniz kurun: TSOB, Shopper Baskets ve Shopper Orders	Her yenilemenin fiyatını, promosyonunu ve vergisini yine B2C Commerce hesaplar
Abonelik platformu zaten fiyatlandırıyor ve tahsil ediyor	Orders API `createOrders`	Tamamlanmış siparişleri içe aktarır; checkout mantığı dışarıda yaşar
Ana PSP Klarna ve site SFRA üzerinde	Klarna'nın abonelik özelliğini değerlendirin	Ödeme cartridge'ıyla birlikte gelir; dokümante edilmiş kısıtlarını kontrol edin
Salesforce B2B ya da D2C Commerce'te yalnızca dijital abonelikler	Commerce Subscriptions	Orada yerleşik, ayrı lisanslı

Uygulama kontrol listesi

Kontrol	Neden önemli
Ana kayıt sistemi ve yenileme tahsilatını yapan sistem yazılı olarak belirlendi	İki sahip ya çift tahsilat yapar ya da yenilemeyi kaçırır
PSP, kendi cartridge sürümünüzde, takviminize uygun merchant-initiated tahsilatı destekliyor	Kayıtlı kart tek başına bunu garanti etmez
API hook çalıştırma açık ve yenileme sepetleri `dw.order.calculate` çalıştırıyor	Promosyon, vergi ve kargo storefront ile aynı olur
Kayıt ve yenileme için tek bir abone ol ve kazan kuralı var	İlk fiyatla sonraki fiyatlar arasındaki kaymayı önler
TSOB login'leri abone bazında gruplanıyor, `login_id` sabit	HTTP 409'u ve mükerrer shopper kayıtlarını önler
Yenileme siparişleri bir custom attribute ile işaretli	OMS, finans ve müşteri hizmetleri onları filtreleyebilir
Hata yolları tasarlandı: ödeme, stok, yayından kalkan ürün, adres	Müşteri kaybını mutlu yoldan (happy path) çok bu yollar belirler
Hesap sayfaları atlama, duraklatma, tarih, adres, kart ve iptali kapsıyor	Self-servis destek taleplerini azaltır
Yenileme çalıştırmaları yoğun trafik saatlerinden uzağa zamanlandı	Yenilemeler aynı instance'ın kaynakları için shopper'larla yarışır

Önemli çıkarımlar

B2C Commerce'te abonelik motoru yoktur; Commerce Subscriptions, dijital ürünler için bir B2B ve D2C Commerce özelliğidir.
Çoğu B2C Commerce sitesi, ana kayıt sisteminin platform içinde mi dışında mı olduğunu netleştirdikten sonra bir partner cartridge ile başlamalıdır.
Özel geliştirmeler yenilemeleri SLAS TSOB, Shopper Baskets ve Shopper Orders ile oluşturur ya da fiyatı hesaplanmış siparişleri Orders API ile içe aktarır.
Token'lar PSP'de kalır ve yenilemeleri yalnızca bir sistem tahsil eder.
Satır bazında abone ol ve kazan, hesaplama hook'unda bir custom price adjustment'tır; abonelik hesap sayfaları SFRA'da da PWA Kit'te de özel geliştirme gerektirir.

Abonelik cartridge'ı seçmek, bir yenileme siparişi akışını gözden geçirmek ya da yinelenen siparişler için ödeme tokenizasyonu tasarlamak, sunduğum SFCC mimari ve geliştirme hizmetlerinin bir parçası; böyle bir proje planlıyorsanız benimle iletişime geçin.

Ek kaynaklar

Sell and Manage Digital Subscriptions in B2B and D2C Stores: Commerce Subscriptions'ın kapsamı, ön koşulları ve lisanslaması.
SLAS Trusted System on Behalf Authorization: TSOB token akışı ve kısıtları.
Build Baskets and Place Orders: SCAPI checkout'u ve ödeme token'ı kuralı.
Orders API: üçüncü taraf sistemlerin oluşturduğu siparişler için createOrders.
Adyen for Salesforce Commerce Cloud: yinelenen ödemeler dahil eklentinin özellik tablosu.
About subscription contracts (Shopify): Shopify'ın contract'ları ve yenileme siparişlerini nasıl oluşturduğu.

SFCC Abonelik: Commerce Cloud'da Abonelik Satışı Nasıl Yapılır