Guide till förhandsgodkännande och återbetalning av laddning av elbilar

1. Varför laddning av elbilar ibland använder en betalningsspärr

I början av en laddningssession kanske operatören inte vet den slutliga energileveransen eller varaktigheten. Förhandsgodkännande är ett sätt att kontrollera att det finns tillgängliga medel innan en tjänst tillhandahålls med en variabel totalsumma. Det är inte den enda modellen: plånböcker, förbetalda saldon och kontofakturering följer olika arbetsflöden.

Auktoriseringsbeloppet bör återspegla en dokumenterad affärspolicy. En onödigt hög reservation kan frustrera förare, medan ett för lågt belopp för den avsedda sessionen kan skapa inkassorisk. Rätt tillvägagångssätt beror på din publik, betalningsleverantör, genomsnittlig session och vilka insamlingsalternativ som stöds.

För den grundläggande skillnaden, se Stripes dokumentation om separat auktorisering och insamlingDen dokumentationen beskriver giltiga metoder och när auktoriseringen upphör. Det betyder inte att varje gateway eller lokal betalningsmetod använder samma regler.

2. Håll auktorisering, insamling, avbokning och återbetalning separata

Dessa villkor är viktiga eftersom nästa åtgärd beror på det aktuella läget. En session som aldrig startade kan behöva en auktoriseringsavbokning. En avslutad och registrerad session med en felaktig avgift kan behöva en delåterbetalning. Att kalla båda situationerna "återbetald" gör att förarna undrar varför deras kontoutdrag ser annorlunda ut.

Betalningsstatus bör också vara separat från debiteringsstatus. ”Debitering slutförd” bevisar inte att inkasseringen lyckades, och ”betalning godkänd” bevisar inte att el levererades. Dina register måste länka båda processerna utan att behandla dem som samma händelse.

3. Utforma det normala sessionsflödet

Innan betalning, visa tariffen, eventuella extra avgifter och den föreslagna reservationen på ett tydligt sätt. Förklara att auktoriseringen är tillfällig och att den slutliga debiteringen beror på sessionen. Ange denna information där föraren fattar betalningsbeslutet, inte bara på en lång sida.

Efter auktorisering, begär laddningsstart och vänta på lämpligt bevis från laddaren. Spara sessionsidentifieraren och betalningsreferensen tillsammans. Om laddaren inte startar inom det överenskomna arbetsflödet, visa en användbar status och följ den definierade avboknings- eller utredningsprocessen.

När sessionen är avslutad, beräkna avgiften utifrån de registrerade uppgifterna och tillämplig tariff. Skicka in den stödda insamlingsåtgärden, registrera resultatet och utfärda ett kvitto med slutbeloppet. Kvittot ska identifiera plats, kontakt, tidsperiod, debiteringsmängd och supportväg.

I ett förenklat exempel auktoriserar en operatör $30 och den verifierade sessionsavgiften är $8,40. Om leverantören stöder det överenskomna arbetsflödet för partiell insamling samlar systemet in $8,40 och hanterar den oanvända auktoriseringen enligt leverantörens regler. Detta är en illustrativ transaktion, inte ett rekommenderat reservbelopp.

4. Definiera vad som händer när resan avbryts

Tänk på fallet där auktoriseringen lyckas men laddaren avvisar startförfrågan. Plattformen ska inte tolka betalningsgodkännandet som en slutförd laddningstjänst. Den måste koppla den misslyckade starten till den relaterade betalningen och följa den dokumenterade avbokningspolicyn.

Ett annat vanligt fall är en avbruten anslutning i slutet av debiteringen. Det slutliga mätarvärdet kan komma senare än vad betalningsflödet förväntar sig. Definiera hur systemet väntar, försöker igen eller eskalerar utan att hitta ett slutgiltigt belopp. Där lokala data kan återställas, använd dessa bevis genom den överenskomna avstämningsprocessen.

En session kan också kosta mer än den initiala auktoriseringen. Anta inte att plattformen helt enkelt kan samla in ett större belopp. Ytterligare auktorisering, stegvis auktorisering eller en annan insamlingsmetod kan krävas, beroende på leverantörens stöd och den kommersiella konfigurationen. Bestäm detta beteende innan lansering.

Om auktoriseringen löper ut innan den registreras, behandla den som ett specifikt undantag med en ägare. Giltighetsfönster som stöds varierar, så integrationen bör använda leverantörens betalningsstatus och utgångsdatumsinformation snarare än en universell hårdkodad tidsfrist.

5. Ge återbetalningar ett eget granskningsbart arbetsflöde

En återbetalning börjar med en redan indriven betalning. Operatören behöver en orsak, ett godkänt belopp och en länk till den ursprungliga transaktionen. Systemet ska registrera vem som begärde den, vem som godkände den där så krävs och om leverantören accepterade, slutförde eller avvisade begäran.

Delvis återbetalning är användbar när endast en del av avgiften behöver korrigeras. Till exempel kan energiavgiften vara giltig medan en felaktigt tillämpad tomgångsavgift behöver återbetalas. Behåll originalkvittot och registrera justeringen istället för att i tysthet skriva om transaktionshistoriken.

Stripes återbetalningsdokumentation skiljer mellan att annullera ofullständiga betalningar och återbetala lyckade betalningar och beskriver väntande eller misslyckade resultat. Bygg supportrutiner kring leverantörens faktiska tillstånd. En inskickad återbetalningsbegäran bör inte automatiskt bli ett meddelande som lovar att pengar har nått föraren.

Undvik att lova en fast utbetalnings- eller återbetalningstid om inte leverantörens och den utgivande bankens villkor stöder det. Förklara vad ert system har gjort och ge kunden en betalningsreferens för uppföljning.

6. Gör integrationen motståndskraftig mot upprepade eller fördröjda händelser

Betalningsmeddelanden är en del av den operativa designen, inte bakgrundsstyrning. En förare kan stänga webbläsaren, en mobilanslutning kan brytas och betalningsleverantören kan leverera en händelse efter att den synliga debiteringsskärmen har slutat uppdateras. Backend-systemet behöver fortfarande uppnå rätt ekonomisk status.

Använd verifierade leverantörsmeddelanden och kontrollera det aktuella betalningsobjektet vid behov. Registrera händelseidentifierare, skydda åtgärder mot dubbelbehandling och ta hänsyn till händelser som inträffar i fel ordning. En upprepad avisering bör inte skapa en andra insamling eller återbetalning.

Stripes webhook-dokumentation förklarar hantering av asynkrona händelser, signaturverifiering och leveransöverväganden. Din implementering bör följa den valda leverantörens krav. Operativt sett behöver personalen också en kö med olösta ärenden snarare än en grön instrumentpanel som döljer saknade aviseringar.

Det befintliga Guide till integration av API för laddning av elbilar ger ett bredare sammanhang för att koppla plattformen till betalnings- och affärssystem. Definiera betalningstillståndsmodellen explicit i projektets omfattning.

7. Stäm av sessions-, betalnings- och avvecklingsposterna

En användbar daglig granskning kopplar samman tre vyer: vad laddaren levererade, vad föraren debiterades och vad leverantören rapporterar för avräkning. Matcha register med stabila identifierare, inte bara ett belopp och en ungefärlig tid. Två olika förare kan enkelt ha sessioner med identiska priser.

Flagga sessioner utan en slutförd betalning, betalningar utan motsvarande session, dubbletter av inspelningar och återbetalningar som väntar på lösning. Tilldela varje undantag till teamet som kan undersöka det. Ekonomiavdelningen bör också förstå hur leverantörsavgifter och förlikningsjusteringar visas.

Direkta kortbetalningar och roamingbetalningar är olika relationer. Om föraren debiterade via en extern mobilitetsleverantör kan den kommersiella avstämningen bero på partnerregister och fakturor. För det arbetsflödet, läs Guiden till roamingavstämning från CDR till avveckling snarare än att tillämpa ett direktkortsförfarande oförändrat.

8. Testa de obekväma fallen före lansering

Kör kontrollerade tester för nekad auktorisering, lyckad auktorisering följt av en misslyckad start, en normal partiell registrering, dubbla återanrop, en försenad slutlig sessionspost och en utgången auktorisering. Lägg till fullständiga och partiella återbetalningar, inklusive en återbetalning som fortfarande väntar eller misslyckas.

Kontrollera fyra saker i varje fall: förarmeddelandet, laddningssessionens status, leverantörens betalningsstatus och ekonomiposten. Alla fyra bör berätta en enhetlig historia. En tekniskt lyckad API-förfrågan kan fortfarande skapa en förvirrande kundupplevelse om formuleringen beskriver fel händelse.

Låt supportpersonalen repetera förklaringen till en väntande reservation. De ska kunna hitta auktoriseringen, den slutliga debiteringen och relevant referens utan att begära onödig bankinformation från kunden.

Vanliga frågor

Är en avgift för laddning av elbil en extra avgift?

En reservation reserverar medel; det är inte nödvändigtvis en ytterligare slutförd avgift. Förare bör kontrollera om beloppet är väntande eller reglerat. Operatörer bör tillhandahålla det slutliga kvittot och undersöka eventuella avvikelser mellan det insamlade beloppet och den verifierade sessionsavgiften.

Kan alla betalningsmetoder använda förhandsgodkännande?

Nej. Supporten beror på metod, leverantör, handlarens konfiguration och region. Vissa betalningsprocesser kräver istället en förbetald, omedelbar betalnings- eller kontofaktureringsmodell. Bekräfta den faktiska integrationen innan du annonserar en viss betalningsupplevelse.

Varför kan en återbetalning vänta?

Resultatet beror på leverantören och transaktionens status, och slutförandet kan involvera den utfärdande banken. Ett supportteam bör skilja mellan en återbetalningsbegäran och en slutförd återbetalning och använda leverantörens referens vid undersökning.