CE 6.4 & PayPal Checkout 2.1 - Troubleshooting

Ich danke Dir so sehr … danke !!
Ich würde es gerne glatt so machen und probieren wie von Dir angegeben … ABER

Eine Frage hätte ich noch und wäre Dir sehr dankbar wenn Du noch darauf antworten möchtest.

Paypal meinte zu mir das ich kein “onBoarding” machen muss, da mein bestehender Paypal-Account ausreichend geprüft und aktualisiert wurde. Ich habe aktuell PayPal Plus installiert und das darf nicht kaputt gehen. Ich habe sorge das wenn ich das onBoarding für den Checkout mache dann mein Account zerschossen oder irgendwas umgestellt wird und mein PaypalPlus danach nicht mehr funktioniert. Ich logge mich da ja in meinen bestehenden Account ein. Kannst Du mir diese Sorge nehmen?

Man hat dann mit mir zusammen unter DEVELOPER eine neue API samt Secret eingerichtet. Nur mit dem webhook konnte man mir nicht weiterhelfen. Ich verstehe ja wozu er da ist, aber wie sieht mein webhook für OXID aus? Ich weiss nicht wie ich da weiter kommen soll und wie ich an meinen/einen webhook ran komme.
Unter DEVELOPER hatte ich einfach meine SHOP-URL angegeben und zum testen irgendeinen Parameter angeklickt aus der langen Liste was Paypal anzeigt.

Du bist gerade der Lichtblick am Horizont und es wäre super lieb wenn Du noch helfen/antworten könntest. Danke!

Den Webhook kann man - wie Du ja gesehen hast - auch manuell anlegen. Sowohl im Developer-Account als auch in Deinem Live-Account.

Als URL nimmst Du https://www.DeinXYZShop.de/index.php?cl=oscpaypalwebhook

Als Events diese Liste:

  • CHECKOUT.ORDER.COMPLETED
  • CHECKOUT.ORDER.APPROVED
  • CHECKOUT.PAYMENT-APPROVAL.REVERSED
  • PAYMENT.CAPTURE.DENIED

Die erzeugte Webhook-ID kommt dann in die Konfiguration des Shops.

Bei Deinem Testsystem nur darauf achten, dass PayPal an diese URL rankommt. Ansonsten musst Du für Deine Tests auf die nachgelagerten Prozesse bzw. die aufwendigeren Payments erst einmal verzichten. Leider gibt es von PayPal nur eine sehr sehr lange IP-Liste (die sich auch immer mal wieder ändert) die man htaccess-seitig freigeben kann. Darum würde ich nicht 100% auf das IP-Whitelisting setzen …

Du kannst die Credentials von PayPalPlus und Checkout auch gemeinsam nutzen. Probiere es am besten für Dich auch noch einmal aus. Nimm die neu generierten Sandbox-Credentials aus Deinem Developer-Account und nutze sie ebenfalls in der PayPalPlus-Sandbox auf Deinem Testsystem.

Beide Module können parallel betrieben werden. Das macht im Frontend natürlich keinen Sinn aber dafür während der Migration im Backend. Ursprünglich war es geplant die Bestellungen aus dem PP- und PPPlus-Modul sauber in das PPCheckout-Modul zu migrieren. Das klappte leider nicht, da Bestellungen, die mit einer bestimmten API erzeugt wurden (PP = SoapAPI, PPPLus = Orders API v1, PPCheckout = Orders API v2), auch nur mit dieser API weiter abgerufen und bearbeitet werden können.
Das bedeutet, solange Du mit Deinen PPPlus-Bestellungen aktiv zu tun hast, empfehle ich Dir das PPPLus-Modul noch aktiv zu lassen und lediglich die PPPlus-Zahlarten im Frontend zu deaktivieren. Wenn Du die “aktive” Phase beendet hast, kann Du das PPPlus-Modul deaktivieren. Solange Du dann auf der Datenbank kein Kehraus machst und noch die PPPLus-Tabellen löschst, kannst Du Dir die PPPlus-Orders auch noch im PPCheckout-Order-Tab anschauen. Da greifen wir “nur” lesend auf die Tabellen zu, also nicht auf die API. Das gilt auch für die Orders aus dem PP-Modul. Solltest Du auch die jeweiligen Module-Tabellen löschen, dann bleibt Dir als letzte Instanz nur noch das PayPal-Backend. Im PayPal-Backend sind gleichzeitig alle drei API-erzeugten Orders bearbeitbar. Eine interne Wrapper-Schicht macht es PayPal möglich, das Du als Kunde keinen Unterschied zwischen den Orders siehst (also mit welcher API die Order erzeugt wurde).

2 Likes

Ich habe gerade noch einmal Rücksprache mit PayPal gehalten. Eine Freischaltung der neuen Zahlarten “Kauf auf Rechnung” (PUI - pay upon invoice) und “Kreditkarte” (ACDC - advanced credit and debit card) für PayPalCheckout kann nicht durch einen Mitarbeiter vom PayPal-Kundensupport vorgenommen werden. Dazu ist der onBoarding-Prozess im Modul vorgesehen. Möglicherweise hat der Mitarbeiter das verwechselt, denn es gab im PPPlus-Modul ja bereits eine Möglichkeit der Kreditkartenzahlung und den Kauf auf Rechnung.

Und ebenfalls noch einmal die Bestätigung: Die Credentials aus PPPlus und PPCheckout sind überkreuz nutzbar. Aber es bringt nichts, einfach nur die PPPlus Credentials in PPCheckout-Modul einzutragen. Ohne die Freischaltung während des onBoardings, sind die neuen Zahlarten “Kauf auf Rechnung” und “Kreditkarte” nicht nutzbar.

Also nutzt das onBoarding :slight_smile:

2 Likes

Hallo, das würde ich gern tun. Aber!
Da man ja die Paypal Daten des Kunden nicht hat, muss dieser das onBoarding durchführen. Das hat schon zweimal nicht geklappt.

Ich kenne das Dilemma. Das PayPal-Konto wird - zurecht - gehütet wie ein Gral. Mein Vorschlag ist in so einer Situation: Probiert es als Entwickler erst einmal selbst mit einem Sandbox-Account. Das macht den Umgang mit dem “rumpeligen” onBoarding für Euch sicherer. Anschließend mit dem Kunden verabreden und in einer Screen-Session dem Kunden beim onBoarden begleiten.

Ich danke Dir und werde heute Nacht in Ruhe alles testen und Deinen Anweisungen folgen. Ich hoffe so sehr das es klappen wird. Danke!

Die Einrichtung war erfolgreich und funktionierte wunderbar, vielen Dank.

Es konnten aber leider nicht alle Events gefunden werden “CHECKOUT.PAYMENT-APPROVAL.REVERSED” findet sich in keiner Konstellation, dafür aber “Payment capture reversed” ?
Eine Liste der Auswahl von PayPal ist am Ende beigefügt, die ist sehr lang.

All events 
Billing plan activated
Billing plan created
Billing plan deactivated
Billing plan pricing-change activated
Billing plan pricing-change inprogress
Billing plan updated
Billing subscription activated
Billing subscription cancelled
Billing subscription created
Billing subscription expired
Billing subscription payment failed
Billing subscription re-activated
Billing subscription suspended
Billing subscription updated
Catalog product created
Catalog product updated
Checkout checkout buyer-approved
Checkout order approved
Checkout order completed
Checkout order saved
Checkout order voided
Collection activity executed
Compliance process agent-action-initiated
Compliance process completed
Compliance process end-user-action-required
Compliance process exempted
Compliance process failed
Compliance process not-applied
Compliance process system-action-initiated
Customer-support chargeback decision-responded
Disputes created
Disputes resolved
Disputes updated
Customer managed-account created
Customer managed-account risk-assessed
Customer managed-account updated
Customer merchant-integration capability-updated
Customer merchant-integration product-subscription-updated
Customer merchant-integration seller-already-integrated
Customer merchant-integration seller-consent-granted
Customer merchant-integration seller-email-confirmed
Customer merchant-integration seller-error-bad-request
Customer merchant-integration seller-error-internal-server-error
Customer merchant-integration seller-onboarding-initiated
Customer merchant-integration seller-onboarding-started
Customer partner-financial-account debited
Customer payout completed
Customer payout failed
Customer user-profile password-changed
Identity authorization-consent granted
Identity authorization-consent revoked
Invoicing invoice cancelled
Invoicing invoice created
Invoicing invoice paid
Invoicing invoice refunded
Invoicing invoice scheduled
Invoicing invoice updated
Loyalty rewards-payout completed
Merchant onboarding completed
Merchant partner-consent revoked
Payment-networks alternative-payment completed
Payment authorization created
Payment authorization voided
Payment capture completed
Payment capture denied
Payment capture pending
Payment capture refunded
Payment capture reversed
Payment order cancelled
Payment order created
Payment payouts-item blocked
Payment payouts-item canceled
Payment payouts-item denied
Payment payouts-item failed
Payment payouts-item held
Payment payouts-item refunded
Payment payouts-item returned
Payment payouts-item succeeded
Payment payouts-item unclaimed
Payment payoutsbatch denied
Payment payoutsbatch processing
Payment payoutsbatch success
Payment refund completed
Payment sale completed
Payment sale denied
Payment sale pending
Payment sale refunded
Payment sale reversed
Payments payment created
Payment networks instrument linked-account-updated
Pricing commission-config created
Pricing commission-config provisioned
Pricing commission-config updated
Risk dispute created
Taxes reports delivered
Taxes reports generated
Vault credit-card created
Vault credit-card deleted
Vault credit-card updated
Vault payment-token created
Vault payment-token deleted
Vault payment-token deletion-initiated

Erst mal vielen Dank für die Anleitung.
Es ist wirklich doof das sich das nicht auf einem lokalen Testsystem vor dem livebetrieb testen lässt.
Im Aktiven Shop rumzutesten macht keinen Spaß.

Ein Sandbox Account kann ich nicht erstellen.
Fenster öffnet sich
E-Mail Adresse eingeben
Auswahl ob Geschäfts oder Privatkunde
Ladeanimation
Wieder E-Mail Adresse eingeben, Weiter-Button funktionier aber nicht mehr.

Live Account neu erstellen geht auch nur halb. Alles nach der Anleitung oben gemacht. Es steht es ist fertig aber die Daten werden nicht in den Shop übernommen. Ich habe im Chrome extra auf die Bestätigung gewartet.

Der WebHook wurde aber bei PayPal angelegt und Rechnung und KK auch freigeschaltet. Ich habe die daten jetzt per Hand reinkopiert.


Fehler bei der Bestellung:
Ich bin eingeloggt gehe im Warenkorb auf weiter, Adresse eingeben, Zahlungsart PayPal, Bestellung bestätigen, dann kommt erst die PayPal Anmeldung (das ist etwas ungewohnt da die Bestellung nun schon im Shop angelegt wird obwohl die Zahlung noch nicht durch ist) und fertig. Die Bestellung ist im Shop aber ich habe wieder 2 unterschiedliche Transaktions-IDs. Eine bei PayPal und eine in meiner Datenbank unter OXTRANSID

OXID Logger.ERROR: POST https://api.paypal.com/v2/checkout/orders/*****/capture returned: 422 Unprocessable Entity Returned Message: The requested action could not be performed, semantically incorrect, or failed business validation. Error Details: [{"issue":"ORDER_ALREADY_CAPTURED","description":"Order already captured.If 'intent=CAPTURE' only one capture per order is allowed."}] Response: {"name":"UNPROCESSABLE_ENTITY","debug_id":"*****","links":[{"href":"https:\/\/developer.paypal.com\/docs\/api\/orders\/v2\/
#error-ORDER_ALREADY_CAPTURED","rel":"information_link","method":"GET"}]} The following curl request could be used to simulate a similar request: curl -v -X POST "https://api.paypal.com/v2/checkout/orders/*****/capture" -H "User-Agent: GuzzleHttp/7" -H "Host: api.paypal.com" -H "PayPal-Client-Metadata-Id: " -H "Content-Type: application/json" -H "PayPal-Auth-Assertion: " -H "Prefer: return=minimal" -H "Authorization: Bearer *****" -d {} ["[object] (OxidSolutionCatalysts\\PayPalApi\\Exception\\ApiException(code: 422): POST https://api.paypal.com/v2/checkout/orders/*****/capture returned: 422 Unprocessable Entity\nReturned Message: The requested action could not be performed, semantically incorrect, or failed business validation.\nError Details: \n[{\"issue\":\"ORDER_ALREADY_CAPTURED\",\"description\":\"Order already captured.If 'intent=CAPTURE' only one capture per order is allowed.\"}]\n\nResponse: \n{\"name\":\"UNPROCESSABLE_ENTITY\",\"debug_id\":\"*****\",\"links\":[{\"href\":\"https:\\/\\/developer.paypal.com\\/docs\\/api\\/orders\\/v2\\/
#error-ORDER_ALREADY_CAPTURED\",\"rel\":\"information_link\",\"method\":\"GET\"}]}\n\nThe following curl request could be used to simulate a similar request:\n \ncurl -v -X POST \"https://api.paypal.com/v2/checkout/orders/*****/capture\" -H \"User-Agent: GuzzleHttp/7\" -H \"Host: api.paypal.com\" -H \"PayPal-Client-Metadata-Id: \" -H \"Content-Type: application/json\" -H \"PayPal-Auth-Assertion: \" -H \"Prefer: return=minimal\" -H \"Authorization: Bearer *****" -d {} at *****/oxid6-4/vendor/oxid-solution-catalysts/paypal-client/src/Service/BaseService.php:45)\n[stacktrace]\n

Der Error Log zeigt einen Eintrag mit der Nummer aus der Datenbank. Anscheinend funktioniert die Rückmeldung nicht und es wird einfach eine neue ID vergeben.


Paypal Express Fehler:
Nicht eingeloggt, Artikel im Warenkorb, PayPal Button klicken, bei PayPal einloggen, Zahlung bestätigen.

Ich lande wieder im Shop, Warenkorb ist leer. Fehlermeldung: Die Aktion konnte nicht abgeschlossen werden. Bitte versuchen Sie es noch einmal!
Der Fehler sagt die Bestellung wurde nicht gefunden. Kann sie ja auch nicht, da sie in dem Moment erst angelegt werden soll.

OXID Logger.ERROR: Shop Order for PayPal order '*****' not found ["[object] (OxidSolutionCatalysts\\PayPal\\Exception\\WebhookEventException(code: 0): Shop Order for PayPal order '*****' not found at *****/oxid6-4/vendor/oxid-solution-catalysts/paypal-module/src/Exception/WebhookEventException.php:26)\n[stacktrace]\n

Bestellung per Rechnung geht durch aber ich habe wieder keine TransaktionsID in der Datenbank OXTRANSID. Außerdem wieder einen Fehler im Errorlog:

 OXID Logger.ERROR: Event verification failed ["[object] (OxidSolutionCatalysts\\PayPal\\Exception\\WebhookEventVerificationException(code: 0): Event verification failed at ****/oxid6-4/vendor/oxid-solution-catalysts/paypal-module/src/Core/Webhook/EventVerifier.php:71)\n[stacktrace]\n

Ich habe das Modul nun wieder deaktiviert damit der Shop morgen sauber läuft.

Gute Nacht

Da wurde beim Eingeben der Umbruch vergessen für die Listenansicht. Gemeint sein könnte

  • CHECKOUT.PAYMENT
  • APPROVAL.REVERSED

Update: Sicher bin ich mir auch nicht, weil es gibt auch welche mit einem Minus unter https://developer.paypal.com/api/rest/webhooks/event-names/

CHECKOUT.PAYMENT-APPROVAL.REVERSED scheint es zu geben Subscribe to checkout webhooks

Die beiden finde ich aber nicht in der Liste von Paypal. Die Liste habe ich oben stehen.

Ja, dies kann ich bestätigen. In meinem Sandbox Account finde ich nur

  • CHECKOUT.ORDER.COMPLETED
  • CHECKOUT.ORDER.APPROVED
  • PAYMENT.CAPTURE.DENIED

zum Auswählen beim Anlegen eines Webhooks bei My Apps & Credentials.

Daher habe ich nur die 3 Auswahlen getroffen.

Die Angabe

  • CHECKOUT.PAYMENT-APPROVAL.REVERSED

fehlt in der Auflistung. Ggfs. ist dies nur ein Wert welcher vom Shop an PayPal geht und nicht umgekehrt und man in deswegen nicht konfigurieren kann.

Bei mir ist jetzt in meinen Lokalen Testshop die Konfiguration über das Popup durchgelaufen und der neue Browser Tab wird automatisch geschlossen. Plus ich werde im Browser Tab des Admin automatisch ausgeloggt.

Zumindest läuft keine Fehlermeldung in den Error Logs auf.

Werde das gleiche nochmal unter Stage (geschützte Subdomain/Testshop) testen, weil dann ist die Testumgebung besser erreichbar als Lokal auf meinem Rechner.

Ich dachte bei Zahlungsweisen müsse sich ein Paypal-Modul öffnen was alles schicker macht, so wie bei Klarna … aber alles wird ganz normal unspektakulär untereinander geliset im Stil von OXID. Erst ganz am Ende schaltet sich Paypal als letzten Schritt ein.

Ist das bei Euch auch so und ist das richtig?

Kann mir jemand bitte bitte verraten was bei Erstinstallation als Standard für Zahlungsweisen dazu gehören und aktiv sind? Das ist so viel und ich finde keine Übersicht was was ist.

Hallo @illmonkey: Es gibt eine gute Möglichkeit, wie Du das alles in Ruhe in Deiner DEV-Umgebung ausprobieren kannst. Wenn ich es richtig herauslese, arbeitest Du mit einer lokalen Entwicklungsumgebung die nur über http:// erreichbar ist.

  • Richte Dir auf der Developer-Seite (siehe weiter oben) von PayPal die beiden Sandbox-Accounts ein.
  • Benutze NGROK um für Deine Test-Session, Deine lokale URL mit SSL und Webzugriff auszustatten. Ich habe dazu ein kleines Tutorial geschrieben: temporäres SSL für die lokale Entwicklungsumgebung
  • Durchlaufe mit der temporären URL den onBoarding-Prozess für die Sandbox. Konfiguriere Dir die neuen Zahlarten nach Deinem Geschmack und probiere alle Payments in Ruhe aus.
  • Da Dein Testshop in dieser Session dank NGROK für PayPal erreichbar ist, klappen auch alle “aufwendigeren” Payments, bei denen PayPal erst über die Webhooks die erfolgreiche Bezahlung mitteilt.
  • Ist Dir alles klar, schließt Du NGROK. Nun funktionieren zwar lokal die Webhooks nicht mehr, aber das spielt dann keine Rolle, da Du das Prinzip dann verstanden hast.
  • Starte nun den onBoarding-Prozess in der Live-Umgebung mit dem Live-Account. Sollte Dein Kunde Dir die Daten nicht geben wollen, bitte Ihn, eine Screen-Sharing-Session zu starten bei der Du ihm über die Schulter schaust. Die Passwörter wirst Du dann nicht sehen, kannst aber helfen, wenn Deinem Kunden was unklar ist.
1 Like

Hmm… Beim PayPal Developer Account bin ich auch ein bisschen verwirrt beim Onboarding Assistenten zu Beginn. Ich hatte zu Beginn die E-Mail Adresse vom PayPal Developer Account genommen - dies hat nicht funktioniert weil die E-Mail zur Freischaltung kam nie.

Dann hatte ich einen automatischen Sandbox Account im Developer Account genommen. Zugangsdaten findet man im PayPal Developer Account wenn man links in der Navigation auf Sandbox Accounts wechselt und einen auswählt. In der Detail Ansicht bekommt man auch das zugehörige Passwort.

Mit einen Sandbox Account konnte ich zuerst den Onboarding Assistenten erstmalig erfolgreich durchlaufen.

Bei mir ist es nur dran gescheitert, dass ich nach schließen des Popup aus dem Admin ausgeloggt wurde.

Konnte meinen Fehler finden!

Da ich bereits die Template Engine Twig in meinem Fall nutze, hatte ich vorab die Smarty Templates in Twig Templates convertiert und über ein eigenes Addon Modul meine Twig Templates bekannt gemacht.

Dort lag auch der Fehler, in einem Admin Twig Template wurde die Callback URL nicht richtig im JavaScript Code gesetzt. Klassiker falls jemand mal Twig Template Engine einsetzt:

{{ oViewConf.getSslSelfLink()|replace({"&": "&"})|raw }}

Hintergrund ist, dass die Twig Engine selber schon die URL optimiert. Dann hat man aber eine doppelte Optimierung, weil dies macht das OXID Framework für Smarty Template Engine bereits im Hintergrund :crazy_face:

Fazit

Onboarding Assistenten läuft im Sandbox Modus nun auch bei Twig Template Engine. Im nächsten Schritt geht es an die Frontend Theme Integration vom PayPal Checkout Modul für Twig.

Was ich noch nicht verstanden habe wo finde ich den automatisch angelegten Webhook über den Onboarding Assistenten?
Oder ist mein Problem, dass ich den Webhook über einen Sandbox Account aus dem Developer Account anlegen lassen habe?
LIVE hatte ich zum Spaß auch einmal getestet, dort gibt es anscheinend eine automatisch angelegt OXID eShop App aber noch ohne Webhook.

Zur PayPal-Sandbox noch ein paar Worte:

Um die Sandbox zu nutzen, meldet man sich mit seinem echten PayPal-Account (egal ob das ein Business- oder Consumer-Account ist) bei developer.paypal.com an. Auf dieser Developer-Plattform erhält man dann automatisch zwei Sandbox-Accounts: einen Business- und einen Personal-Sandbox-Account. Man kann auch x-beliebig weitere Accounts zum Testen anlegen. Die heißen z.B. so:

[email protected] - Für einen Business-Sandbox-Account
[email protected] - Für einen Personal-Sandbox-Account

Zu den Accounts sind auch gleich Passwörter angelegt, die sich auch sofort ändern lassen.

Mit den beiden Accounts könnt Ihr Euch sofort auf dem PayPal-“Spiegel”-System: https://sandbox.paypal.com anmelden. Diese Plattform ist technisch 1:1 das selbe wie das Live-PayPal-System: https://www.paypal.com. Probiert beide generierten Sandbox-Accounts dort einmal aus. Ihr seht das beide Accounts “gut” mit Sandbox-Geld-Guthaben, Sandbox-Kreditkarten etc. ausgestattet sind.

Wenn Ihr nun im Modul den Sandbox-onBoarding-Prozess mit dem Business-Sandbox-Account “[email protected]” startet, so verbindet Ihr Euren Testshop mit diesem Business-Account. D.h. Ihr findet z.B. den angelegten Webhook des Moduls in diesem Business-Sandbox-Account auf sandbox.paypal.com.

Wenn Ihr nun im Frontend Payments ausprobiert, nehmt Ihr zum bezahlen den Account [email protected]. Nach dem bezahlen seht Ihr in Eurem Personal-Sandbox-Account (auf sandbox.paypal.com) die Zahlungsabgänge und im Business-Sandbox-Account (auf sandbox.paypal.com) die Zahlungszuflüsse. Also alles wie in “echt”.

Da wie gesagt sandbox.paypal.com ein Spiegelsystem ist, sind alle Funktionen und die API identisch. D.h. jeden Fehler den Ihr hier erzeugen könnt, wird es im Live-System auch geben. Und umgekehrt aber auch, jeder nicht erzeugte Fehler tritt auch im Live nicht auf. Darum empfehle ich die Integration zuerst mit einem Sandbox-System zu probieren. Wenn alles klappt dann nur die Wiederholung in Live.

1 Like

@Mario_Lorenz wo genau sieht man den automatisch angelegten Webhook im Business-Sandbox-Account?

Oder muss man noch die API-Genehmigung erteilen?

Update: Über sandbox.paypal.com sieht man den Webhook wahrscheinlich nicht. Über developer.paypal.com gibt es Links in der Navigation den Punkt API Calls und wenn ich dort gucke stimmt etwas nicht. In der Übersicht zeigt er mir Status 201 an:

Aber wenn ich auf die Detailansicht handelt es sich um einen Status 400. Also liegt es dort noch an meiner lokalen Testumgebung, dass PayPal diese nicht erreicht. Also habe ich Erfolgsmeldung bekommen und Werte gespeichert über Sandbox obwohl PayPal 400 in Sandbox bekommen hat… :face_with_peeking_eye:

Glaube das Tool versucht je nachdem wo man klickt den Request zu debuggen also zu wiederholen. Aber die Testumgebung ist aus und daher der 400er Status. Schwer zu verstehen was dort Historie und was Aktuell.

Ich habe das gerade noch einmal geprüft (PayPal macht es da einem nicht leicht :wink: ):

Beim onBoarding (egal ob Live oder Sandbox) wird eine sogenannte REST API App erzeugt, die dann auch die Webhooks enthält.

Die “Live” - Rest API App findest Du unter:

  • https://developer.paypal.com/ > linke Navi > DASHBOARD > My apps & credentials > Umschalten auf Live > MyApp_Oxid_ESales (hier können auch mehrere, oder anders benamte Apps stehen)
  • Klickst Du auf die App, dann taucht unter LIVE WEBHOOKS der angelegte Webhook auf

Die “Sandbox” - Rest API App findest Du unter:

  • https://developer.paypal.com/ > linke Navi > SANDBOX > Accounts > Hier ist eine Tabelle mit all Deinen angelegten Sandbox-Accounts. Betrachte hier Deinen Business-Account (z.B. [email protected]) > In der Spalte “Manage account” Klick auf die drei Pünktchen “…” > View/Edit Account > Im PopUp Reiter “API Credentials” > Punkt Rest Apps > Hier findest Du mindestens eine App. Da drauf klicken
  • In der APP taucht dann unter SANDBOX WEBHOOKS der angelegte Webhook auf
1 Like

:rofl:

Tipp der unterste Eintrag ist der Aktuellste.

Nach erfolgreichen Onboarding Assistenten Prozesse in meiner Testumgebung wurde über den Assistenten im PayPal Developer Account automatisiert der Webhook mit den Berechtigungen angelegt. Dabei fällt auf über den Assistenten hat der Webhook ganz unten den letzten Eintrag:

Die Auswahl Checkout payment-approval reversed kann man gar nicht manuell vergeben, wenn manuell einen Webhook anlegt. Da fehlt der letzte Punkt in der Liste.

2 Likes