Магазини за компютърен софтуер.
Търговия на дребно с пакетиран и софтуер за изтегляне.
- MCC
- 5734
- Категория
- Miscellaneous Stores
- Поддръжка на Cardflo
- Да
Какво покрива MCC 5734
Кодът на търговска категория (MCC) 5734 е идентификатор по ISO 18245, използван от картовите мрежи за магазини за компютърен софтуер. Аквирери, издатели и регулатори използват този код, за да определят таксите за обмен, таксите за схеми, правилата за измами и категориите за отчитане за всяка транзакция, която обработва Вашият бизнес.
Търговия на дребно с пакетиран и софтуер за изтегляне. Изборът на правилния MCC е от решаващо значение: неправилен код може да доведе до по-високи такси за обмен, допълнителни такси или, в регулирани категории, отхвърлени транзакции и задържане на сметки.
MCC 5734 обхваща търговци, които основно се занимават с продажба на компютърен софтуер, включително пакетиран софтуер, лицензи за изтегляне и все по-често, абонаментни модели за безсрочни лицензи или софтуер като услуга (SaaS).
Покупките варират от индивидуални приложения до решения на корпоративно ниво, като стойността на транзакциите варира драстично. Честотата може да бъде еднократна или повтаряща се за абонаментни услуги.
Връщанията на плащания често се дължат на „неполучаване“ за съдържание за изтегляне (когато връзката за изтегляне не работи или не е изпратена), „не както е описано“ поради проблеми със съвместимостта или неосъществени очаквания за функции, и „измама“ за лицензи за софтуер с висока стойност.
За абонаментни модели, „анулирането не е обработено“ е честа причина за спор. Схеми като правилата Compelling Evidence 3.0 на Visa и програмата Digital Goods на Mastercard имат за цел да разрешат спорове, специфични за цифровото съдържание.
Надеждните инструменти за управление на абонаменти и логиката за повторен опит на Cardflo могат значително да намалят неволното отпадане на клиенти и връщанията на плащания поради „анулирането не е обработено“, което е особено актуално за повтарящи се плащания за софтуер.
Неговото KYB въвеждане осигурява съответствие за широк кръг доставчици на софтуер, включително тези, предлагащи нишови или високорискови приложения.
Търговците на софтуер трябва да конфигурират приемане за незабавна цифрова доставка и абонаментни модели, като приоритизират силни инструменти за предотвратяване на измами отпред, като 3DS2 за единични покупки с висока стойност.
Поради високия характер на CNP, може да се очаква умерен резерв, особено за нововъзникващи търговци. Уверете се, че вашият платежен шлюз поддържа гъвкаво повтарящо се таксуване за абонаменти и надеждна токенизация.
Като се има предвид нематериалния характер, фокусирайте се върху ясни условия за обслужване, политики за възстановяване на средства за цифрови стоки и неопровержимо доказателство за цифрова доставка или достъп, за да смекчите споровете за „неполучаване“ и последващите усилия за възстановяване.
Позиция на придобиващата страна и застрахователна позиция.
Нисък до среден риск стандартен борд, в зависимост от вида на софтуера и бизнес модела. Единични покупки с висока стойност или често повтарящо се таксуване могат да ескалират риска.
Ясните условия за обслужване, политиките за възстановяване на средства и потвържденията за доставка на изтегляне са от решаващо значение.
Профил на спор и отмяна на плащане.
Най-разпространените кодове за причина за връщане на плащания са „13.2 / 4855 (стоката не е получена)“ за проблеми с изтеглянето и „13.1 / 4853 (услугите не са както е описано)“ поради неосъществени очаквания или съвместимост.
За абонаментни услуги често се случва „13.3 / 4837 (анулиране на повтаряща се транзакция)“. За „неполучено“ предоставете връзки за изтегляне, IP дневници, времеви отпечатъци на достъп и изпратени имейли за потвърждение.
За „не както е описано“ представете подробни спецификации на продукта, системни изисквания, лицензионни споразумения и взаимодействия с поддръжката на клиенти. За „анулиране“ покажете доказателство за потвърдени такси, ясни политики за анулиране и доказателство за предишни известия.
Вижте също: chargeback management · payment response codes · Compelling Evidence 3.0.
Запазете обаждане за обхват, за да видите как Cardflo ще ви настрои.
Как Cardflo обработва MCC 5734
- Позициониране с приобретатели, които активно обслужват бизнеси с MCC 5734 във вашия регион.
- Преглед на MCC по време на въвеждане, за да се потвърди правилния код за вашите продукти.
- Поддръжка за рекласификация, ако правилата на схемата или продуктовият микс се променят след стартиране.
- Маршрутизиране чрез множество посредници, за да се запази стабилността на одобренията за широки търговски категории.
- Поддръжка при спорове, настроена за профила на възстановяванията на плащания за смесени продукти, който вижда този MCC.
- Специализиран мениджър за въвеждане, а не обща опашка за билети.
Методи на плащане обикновено активирани.
Контролен списък за включване.
Какво обикновено изискват придобиващите страни при включване на MCC 5734. Cardflo събира тази информация еднократно и я използва повторно за всеки придобиващ орган, през който ви насочваме.
- Регистрация на фирма и документация за действителен собственик (KYB, UBO).
- Шест месеца извлечения от обработка или банкови извлечения, демонстриращи търговски модел.
- Извлечение от продуктов каталог, потвърждаващо, че MCC обхваща действително продадените стоки.
- Политика за възстановяване, замяна и анулиране, показана на мястото на продажба и на уебсайта.
- PCI DSS SAQ, подходящ за средата (A, A-EP или D, според случая).
- Съотношение на връщанията на плащания и история на споровете за последните шест месеца, включително всякакъв статус на програма за наблюдение на Visa или Mastercard.
Вижте също: Know Your Customer (KYC) · high-risk merchant · smart routing.
Разговаряйте със специалист по придобиване относно настройката на вашия MID.
Често задавани въпроси
Как търговците, продаващи софтуер за изтегляне, могат най-добре да се защитят срещу връщания на плащания за „неполучена стока“?
За софтуер за изтегляне физическо доказателство за доставка е невъзможно.
Търговците трябва да съберат убедителни доказателства: IP адрес на изтегляне, времеви отпечатъци на изтегляне, записи за вход на клиента, потвърждаващи достъп, потвърждение по имейл за доставка на връзка за изтегляне и всякакви комуникационни дневници относно успешна инсталация или употреба.
Някои схеми, като Visa по Compelling Evidence 3.0, позволяват доказателство за цифрова доставка и продължителна употреба като силна защита срещу тези искове, особено за транзакции под определени прагове.
Какви специфични предизвикателства срещат абонаментните софтуерни модели (SaaS) по отношение на връщанията на плащания за „анулирането не е обработено“?
За SaaS, „анулирането не е обработено“ (Код на причината на Visa 13.3) е често срещано. Търговците се нуждаят от ясен, лесно достъпен процес за анулиране.
Доказателствата за оспорване включват демонстриране, че клиентът не е анулирал чрез правилните канали, продължителна употреба след предполагаемото анулиране или че заявката за анулиране е получена след крайния срок за таксуване.
Гарантирането, че клиентите получават потвърждения по имейл за абонамента и анулирането си, е от решаващо значение. Инструментите за повтарящо се таксуване на Cardflo предлагат управление на просрочени плащания и ясна комуникация с клиентите, за да минимизират тези спорове.
Има ли специфични правила на схемата за пробни версии, които се преобразуват в платени софтуерни абонаменти?
Да, схемите имат специфични правила за преобразуване от пробна версия към платена. Търговците трябва ясно да разкрият продължителността на пробната версия, сумата, таксувана след пробната версия, и честотата на таксуване по време на регистрацията.
Обикновено трябва да се изпрати уведомителен имейл до картодържателя няколко дни преди преобразуването на пробната версия, напомняйки му за предстоящото таксуване и как да анулира.
Неспазването на тези правила може да доведе до автоматична отговорност за връщане на плащания за спорове за „повтаряща се транзакция“ (Код на причината на Mastercard 4849) или подобни категории.
Кои специфични доказателства са най-ефективни за демонстриране на цифрова доставка и употреба на софтуер за оспорване на искове за „неполучена стока“?
За да се преборите с искове за „неполучена стока“ за цифров софтуер, най-ефективните доказателства включват дневници на IP адреси, показващи успешно изтегляне или достъп от местоположението на картодържателя, времеви отпечатъци на започване и завършване на изтеглянето,
както и всички издадени и впоследствие използвани уникални лицензионни ключове или кодове за активиране.
Доказателство за доставка по имейл, съдържащо връзки за изтегляне или инструкции за достъп, заедно със записи за създаване на акаунт и активност за вход в софтуерната платформа, също служат като убедителни доказателства.
Тези данни помагат да се установи, че цифровият продукт е бил предоставен и, в повечето случаи, достъпен от картодържателя.
Как търговците на софтуер могат да управляват повтарящото се таксуване за абонаменти, за да намалят връщанията на плащания за „анулирането не е обработено“ и да поддържат съответствие?
За ефективно управление на повтарящи се абонаменти и минимизиране на връщанията на плащания за „анулирането не е обработено“, търговците трябва да приложат ясен и лесно достъпен процес за анулиране, в идеалния случай чрез портала за акаунти на клиента или чрез методи за директен контакт.
Предоставете ясни условия за обслужване по време на регистрацията, описващи циклите на таксуване, сумите и политиките за анулиране. Изпращайте известия преди таксуване преди всяко подновяване, особено за годишни абонаменти.
Поддържайте изчерпателни записи за началните дати на абонамента, събитията за таксуване и всякаква комуникация относно анулирания или промени в акаунта. Бързо обработвайте всички заявки за анулиране и предоставяйте потвърждение на клиента, за да осигурите съответствие с PSD2 и правилата на схемата.
Свързани индустрии.
Свързани ръководства.
Готови ли сте да подобрите настройките за плащанията си?
Разкажете ни за вашия бизнес. Ние ще ви свържем с правилните банки акцептанти и правилния маршрут, обикновено в рамките на една седмица.