Met gesplitste zendingen hebt u meer controle over het tijdstip waarop gereserveerde middelen worden vereffend. In plaats van een enkele afwikkeling binnen 7 dagen uit te voeren, zoals het geval is bij een standaard autorisatie, kunt u met gesplitste zendingen meerdere deelafrekeningen uitvoeren.
Alvorens verder te gaan, kan het nuttig zijn om u opnieuw vertrouwd te maken met ons standaardproces afwikkeling . Klik hier voor meer informatie.
Gesplitste zendingen zijn bedoeld voor scenario's waarbij een klant één bestelling voor meerdere artikelen heeft geplaatst, die op verschillende tijdstippen kunnen worden verzonden. Zo kunt u ervoor zorgen dat de klant over het vereiste geld beschikt door het volledige bedrag van de bestelling te reserveren en vervolgens het voor elk artikel vereiste geld te vereffenen naarmate het wordt verzonden.
(Wij verwijzen naar een individuele gesplitste zending als een "splitsing")
Voordelen
Met gesplitste zendingen vermijdt u de mogelijke ongemakken die gepaard gaan met het uitvoeren van meerdere transacties voor één enkele bestelling. Bijvoorbeeld:
- Onvoldoende middelen voor de latere betalingen.
- Mislukte Fraudecontroles (indien ingeschakeld) op latere betalingen.
- Kaart vervalt voor laatste betaling.
- Kaart wordt geweigerd voor laatste betaling.
3-D Secure
Een bijkomend voordeel voor handelaren is dat alle gesplitste zendingen vallen onder de aansprakelijkheidsverschuiving van de oorspronkelijke autorisatie wanneer deze is gewaarmerkt door 3-D Secure.
Neem contact op met uw acquirer voor meer details voordat u live gaat met een oplossing voor gesplitste zendingen via 3-D Secure.
Soorten gesplitste zendingen
Er zijn twee methoden om gesplitste zendingen te verwerken die wij ondersteunen:
- Regelmatig - Uw systeem dient een verzoek in om het vereffeningsbedrag van het oorspronkelijke verzoek te verlagen, wacht tot het geld is verrekend (duurt gewoonlijk minder dan 24 uur vanaf autorisatie) en pas dan kunt u beginnen met het verwerken van gesplitste zendingen.
- Dezelfde dag - Uw systeem dient een verzoek in om het vereffeningsbedrag van het oorspronkelijke verzoek te verlagen, en dan kunt u beginnen met het verwerken van gesplitste zendingen zodra u klaar bent (zelfs vóór afwikkeling).
Vereisten
- Gesplitste zendingen worden alleen ondersteund met kaarten van de merken Mastercard en Visa .
- Neem contact op met ons Support Team om na te gaan of uw acquirerende bank gesplitste zendingen ondersteunt, en of zij al dan niet gesplitste zendingen op dezelfde dag ondersteunen.
Voor MAESTRO, MASTERCARD & MASTERCARDDEBIT
- Een transactie (met authmethod "PRE") moet binnen 30 dagen na autorisatie voor een deel worden afgerekend.
b.v. £50 toegestaan, £10 verrekend (£40 nog gereserveerd). - Gesplitste zendingen kunnen worden verwerkt om de resterende gereserveerde middelen over een periode van 30 dagen te vereffenen.
- Alle gesplitste zendingen moeten, zodra zij zijn begonnen, binnen 30 dagen na de eerste autorisatie worden afgewikkeld.
Voor DELTA, ELECTRON, PURCHASING, VISA & VPAY
- Een transactie (met authmethod "PRE") moet binnen 31 dagen na autorisatie voor een deelbedrag worden verrekend.
b.v. £50 toegestaan, £10 verrekend (£40 nog gereserveerd). - Gesplitste zendingen kunnen worden verwerkt om de resterende gereserveerde middelen over een periode van 31 dagen te vereffenen.
- Alle gesplitste zendingen moeten, zodra zij zijn begonnen, binnen 31 dagen na de eerste autorisatie worden afgewikkeld.
Procesoverzicht
-
Verstuur AUTH verzoek
Wanneer de klant op "Betalen" klikt bij het afrekenen, wordt een AUTH verzoek ingediend bij Trust Payments.
U moet ervoor zorgen dat het JWT de authmethod en splitfinalnumber velden (meer info hieronder). -
Verstuur TRANSACTIONUPDATE verzoek
Dien een TRANSACTIONUPDATE verzoek in via onze Webservices API om de settlebaseamount van het oorspronkelijke AUTH verzoek.
Het eindbedrag van deze AUTH is gelijk aan de kosten van het (de) eerst verzonden artikel(en). -
Dien gesplitste zendingen in
Dien bij elke verzending van nieuwe artikelen verzoeken om gesplitste zendingen in.
Doorloop
Hieronder volgt een voorbeeld van gesplitste zendingen in actie.
Voordat u verder gaat, moet u een basiskennis hebben van de splitfinalnumber veld.
De splitfinalnumber wordt gebruikt om aan te geven hoeveel gesplitste zendingen voor een transactie zullen worden uitgevoerd (dit omvat de initiële AUTH). Dit is typisch het aantal te verzenden artikelen. De splitfinalnumber veld is vereist in het JWT dat wordt gebruikt bij de verwerking van het initiële AUTH verzoek.
De JavaScript Library / Mobile SDK verwerkt een AUTH verzoek voor £100, met de JWT inclusief splitfinalnumber = 4.
In de praktijk betekent dit dat u 3 splitsingen kunt uitvoeren, naast de aanvankelijke AUTH:
1 Bovengeschikte Auth + 3 mogelijke gesplitste verzoeken = splitfinalnumber van 4
U kunt een update uitvoeren via onze Webservices API om een bedrag van £50 van het initiële AUTH verzoek te laten verrekenen. Zodra de oorspronkelijke AUTH is bijgewerkt, blijft er £50 gereserveerd op de bankrekening van de klant die niet is verrekend.
- Als u reguliere gesplitste zendingen verwerkt, moet u wachten tot de eerste AUTH aanvraag is afgehandeld alvorens verder te gaan (dit duurt doorgaans tot 24 uur nadat de eerste AUTH is verwerkt).
- Als uw acquiring bank gesplitste zendingen op dezelfde dag ondersteunt, kunt u verzoeken om gesplitste zendingen zo snel mogelijk verwerken (zie hieronder).
Als u niet zeker weet welke methode van gesplitste zendingen uw acquirerende bank ondersteunt, neem dan contact op met ons Support Team voor hulp.
Volgens het bovenstaande zijn er £50 aan fondsen die verrekend kunnen worden via gesplitste zendingen die via onze Webservices API worden ingediend. U verwerkt de volgende verzoeken voor gesplitste zendingen:
- Verwerk 1e splitsing voor £20 (£50 - £20 = £30 nog te vereffenen).
- Verwerk 2e splitsing voor £10 (£30 - £10 = £20 nog te vereffenen).
- Verwerk 3e splitsing voor £20 (£20 - £20 = £0 nog te vereffenen).
Na de hierboven beschreven splitsingen is het nu niet mogelijk om volgende splitsingen te verwerken. Dit komt omdat:
- Het maximum aantal splitsingen (gedefinieerd in de splitfinalnumber veld) is bereikt.
- Alle op autorisatie gereserveerde middelen zijn vereffend.
Splitsingen kunnen niet worden verwerkt als aan een van de bovenstaande voorwaarden is voldaan.
Als er nog geld over is dat niet binnen de termijn is verrekend zoals beschreven in het gedeelte Vereisten bovenaan deze pagina, wordt dit geld teruggestort op de bankrekening van de klant.
splitfinalnumber specificatie
Aan het gebruik van dit veld worden aanvullende eisen gesteld:
- In de eerste AUTH, de splitfinalnumber moet worden ingediend met een waarde groter dan of gelijk aan "2".
- Deze waarde staat standaard op "1" wanneer deze niet wordt ingediend.
- Als de waarde "1" is, kunnen geen gesplitste zendingen worden uitgevoerd.
- Het is niet toegestaan een groter aantal deelzendingen in te dienen dan toegestaan in de splitfinalnumber.
- Wij raden u aan hetzelfde aantal splitsingen te verwerken dat is opgegeven in de splitfinalnumber
- splitfinalnumber kan niet groter zijn dan 20.
- U kunt de splitfinalnumber na het eerste AUTH verzoek door het indienen van een lagere splitfinalnumber in een volgend splitsingsverzoek. Dit aantal kan nooit lager zijn dan het aantal reeds verwerkte splitsingen, noch kan het ooit worden verhoogd.
1. Dien AUTH aanvraag in
Vereisten
Het oorspronkelijk ingediende verzoek moet voldoen aan de volgende eisen/criteria:
- De betaling moet worden uitgevoerd met een kaart van het merk Visa of Mastercard.
- De accounttypedescription moet ofwel "ECOM" of "MOTO" zijn.
- De authmethod moet "PRE" zijn, om pre-autorisatie aan te geven.
- Het aantal gedeeltelijke vereffeningen moet worden opgegeven in een verplicht veld met de naam splitfinalnumber.
De JWT bijwerken
U moet de payload binnen het JWT om aan de hierboven gespecificeerde vereisten te voldoen, zodat op een toekomstig tijdstip gesplitste zendingen op deze betaling kunnen worden uitgevoerd.
(Voorbeeld:)
{
"payload":{
"accounttypedescription":"ECOM",
"authmethod":"PRE",
"baseamount":"10000",
"currencyiso3a":"GBP",
"sitereference":"test_site12345",
"requesttypedescriptions":["THREEDQUERY","AUTH"],
"splitfinalnumber":"4"
},
"iat":1567701632,
"iss":"jwt.user"
}
{
"payload":{
"accounttypedescription":"ECOM",
"authmethod":"PRE",
"baseamount":"10000",
"currencyiso3a":"GBP",
"sitereference":"test_site12345",
"termurl":"https://payments.securetrading.net/process/payments/mobilesdklistener",
"requesttypedescriptions":["THREEDQUERY","AUTH"],
"splitfinalnumber":"4"
},
"iat":1567701632,
"iss":"jwt.user"
}
Specificatie veld
Veld | Formaat | Beschrijving | |
accounttypedescription | Alpha (20) |
De bron van de transactie.
Voor gesplitste zendingen kan dit alleen worden ingediend als "ECOM" of "MOTO". |
|
authmethod | Alpha (11) | Voor de eerste AUTH moet dit in de aanvraag worden opgegeven als "PRE". | |
baseamount | Numeriek (13) | Het volledige transactiebedrag (het totaal van de gehele bestelling, inclusief alle zendingen). Moet in basiseenheden zijn, zonder komma's of decimalen, dus €10 zou 1000 zijn. (De maximale lengte kan variëren afhankelijk van uw bank - neem contact op met uw bank voor meer informatie). | |
currencyiso3a | Alpha (3) |
De Munt waarin de transactie zal worden verwerkt. |
|
requesttypedescriptions | Lijst |
De te verwerken verzoektypes. |
|
sitereference |
Alfanumeriek & underscore (50) |
De site referentie heeft betrekking op uw individuele account die u bij de installatie hebt ontvangen. Als u uw site referentie niet kent, neem dan contact op met ons Support Team. | |
splitfinalnumber | Numeriek (2) |
Totaal aantal toegestane splitsingen. (inclusief de eerste AUTH aanvraag) Moet 2 of hoger zijn. |
|
termurl | URL (1024) |
Vereist bij het verwerken van 3-D Secure authenticatie met Android/iOS SDK. Deze URL wordt gebruikt om de kaartuitgever te instrueren waarheen de browser van de klant moet worden gestuurd nadat hij is geverifieerd op de ACS van de kaartuitgever. U moet de volgende URL in dit veld invoeren wanneer u 3-D Secure uitvoert: https://payments.securetrading.net/ |
Antwoord
U moet de teruggezonden JWT decoderen. Dit zal over het algemeen dezelfde structuur hebben als een JWT dat wordt teruggestuurd na een standaardbetaling, maar het zal ook de splitfinalnumber ingediend op payload.
2. Dien in. TRANSACTIONUPDATE
U moet een standaard TRANSACTIONUPDATE verzoek met behulp van onze Webservices API, die een lagere settlebaseamount, zoals in dit voorbeeld:
#!/usr/bin/python
import securetrading
stconfig = securetrading.Config()
stconfig.username = "webservices@example.com"
stconfig.password = "Password1^"
st = securetrading.Api(stconfig)
update = {
"requesttypedescriptions": ["TRANSACTIONUPDATE"],
"filter":{
"sitereference": [{"value":"test_site12345"}],
"transactionreference": [{"value":"1-2-3"}]
},
"updates":{"settlebaseamount":"5000"}
}
strequest = securetrading.Request()
strequest.update(update)
stresponse = st.process(strequest) #stresponse contains the transaction response
<?php
if (!($autoload = realpath(__DIR__ . '/../../../autoload.php')) && !($autoload = realpath(__DIR__ . '/../vendor/autoload.php'))) {
throw new Exception('Composer autoloader file could not be found.');
}
require_once($autoload);
$configData = array(
'username' => 'webservices@example.com',
'password' => 'Password1^',
);
$requestData = array(
'requesttypedescriptions' => array('TRANSACTIONUPDATE'),
'filter' => array(
'sitereference' => array(array('value' => 'test_site12345')),
'transactionreference' => array(array('value' => '1-2-3'))
),
'updates' => array('settlebaseamount' => '5000')
);
$api = \Securetrading\api($configData);
$response = $api->process($requestData);
var_dump($response->toArray());
?>
curl --user webservices@example.com:Password1^ <DOMAIN>/json/ -H "Content-type: application/json" -H "Accept: application/json" -X POST -d '{
"alias": "webservices@example.com",
"version": "1.00",
"request": [{
"requesttypedescriptions": ["TRANSACTIONUPDATE"],
"filter":{
"sitereference": [{"value":"test_site12345"}],
"transactionreference": [{"value":"1-2-3"}]
},
"updates":{"settlebaseamount":"5000"}
}]
}'
{
"alias":"webservices@example.com",
"version":"1.00",
"request":[{
"requesttypedescriptions":["TRANSACTIONUPDATE"],
"filter":{"sitereference":[{"value":"test_site12345"}],
"transactionreference":[{"value":"1-2-3"}]},
"updates":{"settlebaseamount":"5000"}
}]
}
<requestblock version="3.67">
<alias>webservices@example.com</alias>
<request type="TRANSACTIONUPDATE">
<filter>
<sitereference>test_site12345</sitereference>
<transactionreference>1-2-3</transactionreference>
</filter>
<updates>
<settlement>
<settlebaseamount>5000</settlebaseamount>
</settlement>
</updates>
</request>
</requestblock>
Vervang <DOMAIN>
met een ondersteund domein. Klik hier voor een volledige lijst.
De settlebaseamount die in deze update zijn ingediend, zullen als eerste worden verrekend. De resterende middelen blijven toegestaan en kunnen op een later tijdstip worden verrekend door verzoeken om gesplitste verzending in te dienen, zoals hieronder beschreven.
3. Dien gesplitste zending in
Gesplitste zendingen worden verwerkt door extra AUTH verzoeken in te dienen via onze Webservices API.
Bij het verwerken van een gesplitste zending erven wij de factuur- en klantgegevens van de oorspronkelijke autorisatie. U kunt bijgewerkte waarden voor de leveringsgegevens gebruiken, door deze velden opnieuw in te dienen in het verzoek voor een gesplitste zending AUTH met behulp van onze Webservices API.
Vereisten
Het verzoek om gesplitste betaling moet aan de volgende eisen/criteria voldoen:
- Moet verwijzen naar een bovengeschikte "PRE" AUTH.
- De requesttypedescription moet "AUTH" zijn.
- De authmethod moet "SPLIT" zijn.
- De accounttypedescription van de splitsing (bijv. "ECOM") moet overeenkomen met die van de bovengeschikte autorisatie.
- De baseamount moet minder zijn dan of gelijk aan de resterende gereserveerde middelen.
- Bij een reguliere gesplitste zending (niet dezelfde dag), de settlestatus van de oorspronkelijke bovengeschikte moet "100" zijn, wat betekent dat de betaling is vereffend.
Verzoek
Het volgende verzoekvoorbeeld dient een splitsing in. Dit volgt dezelfde structuur als een standaard AUTH aanvraag, behalve de authmethod veld moet worden ingediend met de waarde "SPLIT".
#!/usr/bin/python
import securetrading
stconfig = securetrading.Config()
stconfig.username = "webservices@example.com"
stconfig.password = "Password1^"
st = securetrading.Api(stconfig)
auth = {
"sitereference": "test_site12345",
"requesttypedescriptions": ["AUTH"],
"baseamount": "2000",
"orderreference": "My_Order_123",
"accounttypedescription":"ECOM",
"authmethod": "SPLIT",
"parenttransactionreference": "1-2-345678"
}
strequest = securetrading.Request()
strequest.update(auth)
stresponse = st.process(strequest) #stresponse contains the transaction response
<?php
if (!($autoload = realpath(__DIR__ . '/../../../autoload.php')) && !($autoload = realpath(__DIR__ . '/../vendor/autoload.php'))) {
throw new Exception('Composer autoloader file could not be found.');
}
require_once($autoload);
$configData = array(
'username' => 'webservices@example.com',
'password' => 'Password1^',
);
$requestData = array(
'sitereference' => 'test_site12345',
'requesttypedescriptions' => array('AUTH'),
'baseamount' => '2000',
'orderreference' => 'My_Order_123',
'accounttypedescription' => 'ECOM',
'authmethod' => 'SPLIT',
'parenttransactionreference' => '1-2-345678'
);
$api = \Securetrading\api($configData);
$response = $api->process($requestData);
var_dump($response->toArray());
?>
curl --user webservices@example.com:Password1^ <DOMAIN>/json/ -H "Content-type: application/json" -H "Accept: application/json" -X POST -d '{
"alias":"webservices@example.com",
"version": "1.00",
"request": [{
"sitereference": "test_site12345",
"requesttypedescriptions": ["AUTH"],
"baseamount": "2000",
"orderreference": "My_Order_123",
"accounttypedescription": "ECOM",
"authmethod": "SPLIT",
"parenttransactionreference": "1-2-345678"
}]
}'
{
"alias":"webservices@example.com",
"version":"1.00",
"request":[{
"sitereference":"test_site12345",
"requesttypedescriptions":["AUTH"],
"baseamount":"2000",
"orderreference":"My_Order_123",
"accounttypedescription":"ECOM",
"authmethod":"SPLIT",
"parenttransactionreference":"1-2-345678"
}]
}
<requestblock version="3.67">
<alias>webservices@example.com</alias>
<request type="AUTH">
<merchant>
<orderreference>My_Order_123</orderreference>
</merchant>
<billing>
<amount>2000</amount>
</billing>
<operation>
<accounttypedescription>ECOM</accounttypedescription>
<authmethod>SPLIT</authmethod>
<sitereference>test_site12345</sitereference>
<parenttransactionreference>1-2-345678</parenttransactionreference>
</operation>
</request>
</requestblock>
Vervang <DOMAIN>
met een ondersteund domein. Klik hier voor een volledige lijst.
Specificatie veld
Veld | Formaat | Beschrijving | |
accounttypedescription XPath: /operation/accounttypedescription |
Alpha (20) | Moet overeenkomen met de waarde die in het initiële AUTH verzoek is opgegeven (ofwel "ECOM" of "MOTO"). | |
authmethod XPath: /operation/authmethod |
Alpha (11) | Voor de gesplitste zending moet dit worden ingesteld op "SPLIT". | |
baseamount XPath: /billing/amount |
Numeriek (13) | Het bedrag in verband met het verzoek om gesplitste zending. Moet gelijk zijn aan of lager dan het resterende gereserveerde bedrag. Moet in basiseenheden staan, zonder komma's of decimalen, dus €10 zou 1000 zijn. (De maximale lengte kan variëren, afhankelijk van uw overnemende bank - neem contact op met uw bank voor meer informatie). | |
parenttransactionreference XPath: /operation/parenttransactionreference |
Alfanumeriek & koppeltekens (25) |
Dien de transactionreference teruggestuurd in het initiële antwoord op AUTH . Dit is nodig om de betalingsreferenties van dit vorige verzoek te erven. | |
requesttypedescriptions XPath: /@type |
Alpha (20) | U moet "AUTH" invoeren, zoals in het verzoekvoorbeeld. | |
sitereference XPath: /operation/sitereference |
Alfanumeriek & underscore (50) |
Identificeert uw site op het Trust Payments systeem. |
|
orderreference XPath: /merchant/orderreference |
Alfanumeriek, inclusief Aanbevolen lengte 25 tekens of minder (exacte lengte afhankelijk van de wervende bank). Niet-naleving van deze eis kan ertoe leiden dat de tekst in de transactie wordt ingekort. |
Uw unieke bestelreferentie die in het Trust Payments systeem kan worden opgeslagen. | |
splitfinalnumber XPath: /operation/splitfinalnumber |
Numeriek (2) |
Optioneel: U kunt de waarde van het gesplitste eindnummer bijwerken door een nieuwe waarde door te geven in het verzoek om gesplitste zending.
Dit aantal kan nooit lager zijn dan het aantal reeds verwerkte splitsingen, noch kan het ooit worden verhoogd. |
Antwoord
Dit volgt dezelfde specificatie als een standaard AUTH antwoord, behalve de splitfinalnumber ingediend in het verzoek wordt ook geretourneerd. Aanvullende opmerkingen:
- Net als bij een standaard AUTH antwoord moet u de op deze pagina beschreven controles uitvoeren.
- Let op twee specifieke foutcodes voor gesplitste zendingen: "20010" voor een Split-bedrag te hoog, en "20024" voor een Ongeldige gedeelde transactie.
Specificatie veld
Veld | Formaat | Beschrijving | |
accounttypedescription XPath: /operation/accounttypedescription |
Alpha (20) | Moet overeenkomen met de waarde die in het initiële AUTH verzoek is opgegeven (ofwel "ECOM" of "MOTO"). | |
authmethod XPath: /operation/authmethod |
Alpha (11) | Voor de gesplitste zending moet dit worden ingesteld op "SPLIT". | |
baseamount XPath: /billing/amount |
Numeriek (13) | Het bedrag in verband met het verzoek om gesplitste zending. Moet gelijk zijn aan of lager dan het resterende gereserveerde bedrag. Moet in basiseenheden staan, zonder komma's of decimalen, dus €10 zou 1000 zijn. (De maximale lengte kan variëren, afhankelijk van uw overnemende bank - neem contact op met uw bank voor meer informatie). | |
errorcode XPath: /error/code |
Numeriek (1-5) |
De foutcode (errorcode) moet worden gebruikt om te bepalen of het verzoek succesvol was of niet.
Gemeenschappelijke waarden:
Als u wordt teruggestuurd errorcode "20024" in het antwoord, raden wij u aan te controleren of uw implementatie voldoet aan de eisen die op deze pagina staan. Zorg er met name voor dat de authmethod en splitfinalnumber velden worden ingediend met geldige waarden, en dat de baseamount ingediend, niet hoger is dan het totale bedrag dat in het oorspronkelijke verzoek AUTH is toegestaan. Klik hier voor een volledige lijst van errorcode en berichtwaarden. |
|
splitfinalnumber XPath: /operation/splitfinalnumber |
Numeriek (2) | Totaal aantal toegestane splitsingen. |
Afwikkeling
Wanneer uw systeem een geldig verzoek voor gesplitste zendingen indient, zal de settle status van de transactie '0' ('In afwachting van betaling') zijn gedurende maximaal 24 uur voordat deze wordt afgewikkeld (status '100'). Gedurende die tijd kunnen gesplitste zendingen worden geannuleerd (of opgeschort) door de settle status van de gesplitste zending bij te werken:
- U kunt een TRANSACTIONUPDATE verzoek verwerken met onze Webservices API om de Status betaling van een splitsing bij te werken naar "2" voor opgeschort of "3" voor geannuleerd.
- U kunt zich ook aanmelden bij Portal, zoek naar de unieke transactionreference en klik op "Updaten". Wijzig dan de settlestatus van de transactie op "2" of "3", zoals vereist.
Gesplitste zendingen kunnen worden opgeschort, maar moeten worden afgewikkeld binnen het tijdsbestek dat is aangegeven in het gedeelte Vereisten bovenaan deze pagina.
Terugbetalingen
Het is mogelijk om terugbetalingen uit te voeren op elke gesplitste betaling die is vereffend. Wanneer u terugbetalingen overweegt, kunt u elke splitsing het beste beschouwen als een onafhankelijke transactie, omdat splitsingen onafhankelijk van elkaar worden terugbetaald.
Om bijvoorbeeld een enkele autorisatie die in 4 delen is gesplitst (1 Bovengeschikte + 3 gesplitste verzoeken) volledig terug te betalen, moet u minstens 4 terugbetalingen uitvoeren.
Elke splitsing wordt geïdentificeerd aan de hand van hun unieke transactionreference.
Net als bij standaardbetalingen kunt u alleen splitsingen terugbetalen wanneer deze zijn vereffend (Status betaling "100"). Als een splitsing niet is vereffend, kunt u de Status betaling bijwerken om afwikkeling uit te stellen of te annuleren.
De terugbetaling van een enkele splitsing heeft geen invloed op de afwikkeling van andere splitsingen van dezelfde oorspronkelijke AUTH.
Het uitvoeren van een terugbetaling verhindert niet dat toekomstige splitsingen worden verwerkt, mits nog steeds aan alle bovenstaande vereisten is voldaan.
Door op deze wijze terugbetalingen uit te voeren, komen eerder gereserveerde middelen niet beschikbaar voor toekomstige splitsingen van bovengeschikte verzoek.
Als u uw maximum aantal splitsingen heeft bereikt (splitfinalnumber), kunt u met de terugbetaling van een gesplitste betaling geen aanvullend verzoek tot splitsing indienen.
Uw systeem moet een standaard REFUND verzoek indienen via onze Webservices API voor elke splitsing die u wilt laten terugbetalen.
Aanvullende opmerkingen
- Fraudecontroles kunnen niet worden uitgevoerd op splitsingen.
- Duplicaatcontroles worden uitgevoerd op splitsingen (indien ingeschakeld in uw account).
- Gesplitste zendingen ondersteunen geen DCC.