Authentication
Плъгин за търговец
Също: MPI
Компонент от страна на клиента или сървъра, който оркестрира потока от 3DS съобщения с DS и ACS от името на търговец или PSP.
Плъгин за търговец означава: Компонент от страна на клиента или сървъра, който оркестрира потока от 3DS съобщения с DS и ACS от името на търговец или PSP. Може да се появи и като MPI.
При платежните операции това не е просто етикет; той контролира как транзакция, идентификационни данни, рисково събитие или движение на средства се тълкуват от контрагентите.
Механизмът обикновено се намира преди оторизацията, където издателят или упълномощена страна за удостоверяване проверява дали платецът има право да използва идентификационните данни. Данни като информация за устройството, статус на регистрация на издателя, сума на транзакцията и търговски рискови сигнали могат да променят резултата.
Обикновено се анализира заедно с 3-D Secure 2 (EMV 3DS), сървър за контрол на достъпа, тъй като тези съседни концепции определят търговския и оперативен резултат.
Практическите детайли обикновено се намират в регистрационните файлове на шлюза, отчетите на придобиващия, схематичните файлове, записите за обслужване на клиенти и извлеченията за сетълмент, а не в едно табло за управление.
Екипите трябва да записват стойността, времевия печат, контрагента, валутата, кода за отговор и всеки индикатор за освобождаване или отговорност, прикрепен към събитието. Често срещана грешка е да се третира плъгинът за търговец като статична дефиниция.
На практика значението може да се променя според схемата, държавата, MCC, картовия продукт, издателя, канала на транзакцията и дали плащането е инициирано от клиента или от търговеца.
Ето защо търговците с голям обем обикновено документират правила, наблюдават изключенията ежеседмично и преглеждат праговете, преди малък оперативен проблем да се превърне в проблем с обратно плащане, финансиране или съответствие.
Worked example
Търговец преглежда транзакция от 240 евро, където плъгинът за търговец е решаващият фактор. Касата изпраща данни за устройството и транзакцията, рисковият механизъм на издателя решава дали да предизвика клиента, а резултатът от удостоверяването се предава в заявката за оторизация.
Оперативните разходи са моделирани на 0 базисни точки от промяната на междубанковия обмен, но с материално различен резултат от отговорността за измами, а съответното действие трябва да приключи за по-малко от 10 секунди.
Стъпка 1 е да се заснемат оригиналните данни на заявката, включително сума, валута, държава на издателя, MID и код за отговор или статус.
Стъпка 2 е да се приложи наборът от правила на търговеца, например дали да се опита отново, да се предизвика, да се възстанови сумата, да се освободят стоки или да се задържат за преглед.
Стъпка 3 е да се съгласува резултатът с отчитането на придобиващия, така че финансовият отдел да може да види паричното въздействие.
Ако правилото подобри резултата дори с 50 базисни точки при 2000 подобни месечни транзакции, търговецът защитава приблизително 10 допълнителни поръчки от избегнат провал или загуба.
Scheme notes
Visa Secure, Mastercard Identity Check, American Express SafeKey и Discover ProtectBuy се основават на принципите на EMV 3-D Secure, но нивата на предизвикателство на издателя и третирането на отговорността се различават според схемата, региона и статуса на регистрация.
Стойностите на ECI, флаговете за освобождаване, индикаторите за предизвикателство и резултатите от удостоверяване трябва да бъдат правилно предадени за оторизация.
В ЕИП и Обединеното кралство PSD2 SCA създава регулаторна рамка, докато неевропейските транзакции могат да използват същия протокол главно за контрол на измами и прехвърляне на отговорност.
Why it matters for merchants
В търговски план това засяга конверсията, отговорността за измами, съответствието със SCA и баланса между безпроблемното плащане и нивата на предизвикателство.
За търговец, обработващ 500 000 британски лири на месец, движение от 25 базисни точки струва 1250 британски лири преди вторични ефекти като спорове, резерви, билети за поддръжка или разходи за неуспешна доставка.
Въздействието е по-голямо при високорискови модели, абонаменти, пътувания, цифрови стоки и трансгранични модели, тъй като решенията на издателя и мониторингът на схемата могат бързо да се натрупват.
Cardflo може да помогне, като комбинира достъп до придобиване, MID маршрутизация, правила за оркестрация, KYB преглед и инструменти за обратно плащане, където е уместно, така че търговецът да не зависи от една интерпретация на процесора или един фиксиран път на транзакция.
Често задавани
Какви данни трябва да съхранява търговецът за плъгина за търговец?
Съхранявайте ID на транзакцията, MID, придобиващ, сума, валута, държава на издателя, схема на картата, код за отговор или статус, времеви печат и всякакви 3DS, освобождаване, възстановяване или референция за спор.
За картови транзакции запазете идентификаторите за оторизация и клиринг, тъй като въпроси за сетълмент или обратно плащане могат да възникнат 30 до 120 дни по-късно.
За регулирани потоци запазете съгласието на клиента и записите за доказателства за поне периода, изискван от местното законодателство или правилата на схемата. Добрите записи намаляват времето за разследване от часове до минути, когато отчитането на придобиващия не съвпада със системата за поръчки.
Колко често трябва да се преглежда плъгинът за търговец?
Търговците с голям обем трябва да преглеждат нивата на изключения ежеседмично и да проследяват основния показател ежемесечно по схема, придобиващ, държава на издателя, MCC и метод на плащане. Движение от 20 до 50 базисни точки може да бъде съществено, ако търговецът обработва хиляди поръчки.
Финансовият отдел трябва да съгласува паричното въздействие на ниво сетълмент, докато операциите по риск или плащания трябва да анализират основната причина. Прегледът само на общите суми прикрива проблеми, които се появяват в един BIN диапазон, регион или MID.
Какъв праг обикновено задейства действие на плъгина за търговец?
Прагът зависи от категорията, но търговците трябва да разследват всяка внезапна промяна над 10% относително движение или 25 базисни точки абсолютно движение.
За спорове и измами, прагове на схемата като 0,9% при мониторинг на Visa или 1,5% при Mastercard ECM могат да създадат незабавен риск от ескалация. За сетълмент или ценови елементи, дори 5 до 15 базисни точки могат да оправдаят маршрутизация или преглед на договора.
Ключът е да се зададат прагове преди края на месеца, а не след като пристигне фактура от процесор или известие от схема.
Може ли плъгинът за търговец да се различава между придобиващите?
Да. Придобиващите могат да картографират кодовете за отговор по различен начин, да прилагат различни правила за риск, да поддържат различни полета за данни и да се уреждат по различни цикли.
Един придобиващ може да върне общо отхвърляне, докато друг излага съвет от издателя, който позволява безопасно повторно опитване. Третирането на таксите също може да варира според договора, особено за трансгранични, FX, премиум карти и алтернативни методи на плащане.
Ето защо търговците, използващи оркестрация, трябва да сравняват ефективността по придобиващ и схема, вместо да разчитат на една обща цифра за одобрение или разходи.
Коя е първата стъпка за отстраняване, когато плъгинът за търговец създава загуби?
Започнете с 30-дневна извадка и я разделете по схема, държава на издателя, продуктов тип карта, метод на плащане, MID и код за отговор или спор. Количествено определете стойността на риска в парично изражение, а не само в процентни пунктове.
След това решете дали корекцията е оперативна, като по-добри доказателства или комуникация с клиенти, техническа, като по-богати данни или 3DS индикатори, или търговска, като различен маршрут на придобиващия.
Проверете отново същия показател след един пълен цикъл на сетълмент или спор, за да потвърдите, че промяната е проработила.
See how Плъгин за търговец plays out in practice
Industries and regions where this term drives real acquiring, routing, or dispute decisions.
Свързани термини
Текущият стандарт за удостоверяване на EMVCo, изпращащ над 100 елемента данни до издателя за базирана на риск, предимно безпроблемна проверка на клиента.
Компонент от страна на издателя в 3DS поток, който решава между безпроблемно и предизвикателно, издава криптограми и налага правила за SCA.
Протокол за удостоверяване на картови мрежи, който прехвърля отговорността за измами от търговеца към издателя, когато картодържателят е верифициран.
Резултат от 3DS2, при който издателят удостоверява картодържателя само въз основа на данни за устройството и транзакцията, без да се показва предизвикателство на клиента.
Свързани ръководства.
Готови ли сте да подобрите настройките за плащанията си?
Разкажете ни за вашия бизнес. Ние ще ви свържем с правилните банки акцептанти и правилния маршрут, обикновено в рамките на една седмица.