Alles richtig, soweit bin ich auch bei dir. Die Payment-ID ist das Kriterium um Bestellung und Zahlungseingang innerhalb der WAWI zuzuodnen zu können! Die einzelnen Zahlungen (hin und/oder rück) werden dann innerhalb dieser Payment-ID natürlich mit Transaktions-ID in der FIBU nachgewiesen. Mit anderen Worten: Einkauf <-> Payment-ID = es gibt eine Bestellung und zu dieser liegt Zahlungsfluss vor Transaktions-ID = im Zahlungsfluss gibt es Ein- und/oder Auszahlungen
Ich finde "die gesamtgesellschaftliche Entwicklung" schon schwierig, weil ich finde gesellschaftlich bewegen wir uns in viele Richtungen gleichzeitig. Einige find ich gut, andere schlecht. Regeln sind dabei immer ein notwendiger Bestandteil in einem Miteinander, damit nicht jeder machen kann was er will, es braucht eine gewisse Gleichbehandlung und eine Ethik, manchmal verordnet. Wie weit Regeln dann genau gehen müssen ist die nächste spannende Frage, aber auch wieder am Einzelfall zu betrachten und zu bewerten. Mit Pauschalisierung bin ich auch da persönlich nicht einverstanden. Da benennt man einen Trend aus dem Spektrum und redet darüber, das ist aber eigentlich dann auch nur begrenzt ein Thema für dieses Forum. Jede Zahlung hat eine Payment ID. Die Nachvollziehbarkeit eines monetären Vorgangs geniesst quasi gleiche Vorraussetzungen. Der wird gekennzeichnet und zusammengefasst durch eine Payment ID, über die man sich die Subtransaktionen besorgen kann, die dann wieder in einem Gesamtvorgang zusammensetzbar sein müssen. Wir fangen oben an, du kommst in mehreren Schüben von unten und suchst dann oben nach gleichen. Deins ist aufwendiger.
Das ist so nicht ganz richtig. Einer Payment-ID können mehrere Transaktionen zugeordnet sein, das können insbesondere bei Nutzung des Authorize-Capture-Modus auch mehrere Zahlungen sein, wenn der Rechnungsbetrag z.B. wegen Lieferverzögerungen auf mehrere Captures aufgeteilt wird. Einer Bestellung können mehrere Payment-IDs zugeordet sein, einer Payment-ID können mehrere Transaktionen (sale, authorize, order, capture, refund) zugeordnet sein. Also, Bestellung zu Transaktion ist 1:n:m.
Richtig wäre: Jeder Vorgang hate eine Payment-ID, und jede Zahlung hat eine Transaction-ID. Die Zuordnung der Zahlungen zum Vorgang sollten/müssen in der ERP/FIBU stattfinden, da der Kunde ja eventuell noch andere OPs hat, die weder Paypal noch der Gambio-Shop wissen. So gesehen ist die Payment-ID zwar nett zu haben, aber trotzdem als alleiniges Kriterium nicht nutzbar. In der Buchhaltung benötige ich jede Transaktion einzeln, mit eindeutiger ID, so schreibt es die GoB vor. Mir nutzt der Shop nichts, wenn er meint die Bestellung sei mit wer weiß wie vielen Payment-IDs und Transactions-IDs vollständig bezahlt, der Kunde hat aber noch etliches offen, aus alten, nicht mit PayPal getätigten Bestellungen. So gesehen ist die Payment-ID auch nur ein Tropfen im Informationstopf. BTW: Eine Realtimeabfrage bei PayPal aus der FiBu raus wäre nicht zertifizierbar und würde vom Finanzamt bei einer Prüfung erhebliche Probleme mit sich bringen. PS: Könnten wir die Diskussionen zu tagespolitischen Dingen und der Weltlage wo anders fortführen?
Aufwendiger, ja - aber laut Gesetzgeber richtig: 3.2.4 Ordnung (§ 146 Absatz 1 AO, § 239 Absatz 2 HGB) 53 Der Grundsatz der Klarheit verlangt u. a. eine systematische Erfassung und übersichtliche, eindeutige und nachvollziehbare Buchungen. 3.2.4 Ordnung (§ 146 Absatz 1 AO, § 239 Absatz 2 HGB) 57 Die Buchungen müssen einzeln und sachlich geordnet nach Konten dargestellt (Kontenfunktion) und unverzüglich lesbar gemacht werden können. Damit bei Bedarf für einen zurückliegenden Zeitpunkt ein Zwischenstatus oder eine Bilanz mit Gewinn und Verlustrechnung aufgestellt werden kann, sind die Konten nach Abschlusspositionen zu sammeln und nach Kontensummen oder Salden fortzuschreiben (Hauptbuch, siehe unter 5.4) 3.2.5 Unveränderbarkeit (§ 146 Absatz 4 AO, § 239 Absatz 3 HGB) 58 Eine Buchung oder eine Aufzeichnung darf nicht in einer Weise verändert werden, dass der ursprüngliche Inhalt nicht mehr feststellbar ist. Auch solche Veränderungen dürfen nicht vorgenommen werden, deren Beschaffenheit es ungewiss lässt, ob sie ursprünglich oder erst später gemacht worden sind (§ 146 Absatz 4 AO, § 239Absatz 3 HGB). Gerade letzters kann ich nicht garantieren, wenn ich die Daten immer per Payment-ID von PayPal abholen muss. Ich brauche die eindeutigen nachvollziehbaren Daten zu jeder einzelnen Buchung, nicht zu jedem Vorgang oder Bestellung hier in meinen Aufzeichnungen, und das wäre halt nun mal die Transaction-ID. Problem ist zusätzlich, dass im PayPal-Kontoauszug auch keine Payment-ID steht.
Ich möchte nur wissen, ob ich das richtig verstanden habe, aber so wie ich die Sachen von Wilken und Marco lese, ruft man mit der Payment - ID alles ab, was mit der Bestellung zusammen hängt. Also nicht jeden Krümel einzelnen sondern mit einem mal den aktuellen stand. Beispiel: Es gibt eine Bestellung aus 3 Teilen. Das erste Teil ist da, das zweite Teil kommt in 2 Wochen und das dritte in 4. Jetzt zieht man von PP den Betrag für das erste Teil ein und sendest das. Über die Payment-ID bekommt man Bestellung Gesamtsumme als genehmigt mit Datum Teilforderung 1 als bezahlt mit Datum Nach 2 Wochen liefert man das nächste Teil und zieht den Betrag über PP ein. Jetzt sieht man über die Payment-ID (immer noch die gleiche) Bestellung Gesamtsumme als genehmigt mit Datum Teilforderung 1 als bezahlt mit Datum Teilforderung 2 als bezahlt mit Datum Nun sagt der Kunde "Ach nee, das 2 will ich doch nicht" und widerruft. - man veranlasst die Rückzahlung Die Paymemnt-ID liefert Bestellung Gesamtsumme als genehmigt mit Datum Teilforderung 1 als bezahlt mit Datum Teilforderung 2 als bezahlt mit Datum Rückzahlung der Teiforderung 2 mit Datum Ist das so richtig?
Nein. Jeder Vorgang hat eine eigene Transaktions-ID, welche Teil einer Payment-ID ist. Der Vorgang als die Bestellung kann dann aber mehrere Transaktions-IDs und auch mehrer Payment-IDs haben. Wie meinst Du das mit Realtime-Abfrage ? Die Vorgänge werden in der Buchhaltung erfasst und zum Stichtag ans FA übertragen und fest geschrieben, sodass danach keine Änderungen mehr erfolgen. Was ich im Vorfeld mache, also wo ich die Daten herbekommen und über welchen Weg ist dem FA dann doch egal, oder verstehe ich Dich falsch. Daten die zum Zeitpunkt der Erzeugung bereit stehen werden verworfen um sie dann zu einem späteren Zeitpunkt mittels zahlreichen neuen Abfragen wieder zu erhalten (Beispiel Wawi -> REST-API->Paypal->Daten aus der Rückmeldung auslesen und in WaWi zurück schreiben) ist deutlich auf und umständlicher. Wie ist das eigentlich bei anderen Zahlungsdienstleistern ? Die arbeiten alle mit Transaktionen, oder gibt es dort auch welche die soetwas wie eine Payment-ID verwenden ?
Danke Barbara für deine Veranschaulichung. Ich denke genau so will das am Ende doch eh jeder und genau so ist es ja auch GodB Konform und Buchbar, nur muss es halt auch technisch abgebildet werden. Und da liegt der Ball im Spielfeld der WAWI Betreiber....
Deine Buchhaltung darfst nicht mit der Abfrage der Transaktionen bei PayPal vergleichen. Damit du die einzelnen Zahlungen überhaupt in deine Buchhaltung bekommst rufst du mit der Payment-ID den aktuellen Stand bei PayPal ab und bekommst alle Tranaktionen zu dem Vorgang / Bestellung. Die verbuchst dann. Fertig. Ab ans Finanzamt. Nun kommt eine erstattung dazu. Du rufst mit der selben Payment ID wieder den aktuellen Stand ab. Bekommst das schon verbuchte und das neue. Verbuchst dann das neue und wieder fertig. Die Payment ID die due real zur abfrage nutzt ist das Eltern Teil. Falls es neue Kinder bekommen hat erfährst du es durch den live abruf. Das hat nichts mit dem zu tun was du ans Finanzamt übermittelst.
Die Terminologie variiert, aber bei den meisten gibt es eine ähnliche Datenhierarchie, bei der man anhand eines ID-Wertes, den man einer Bestellung (bzw. einem Checkout) zuordnen kann, die weiteren, abhängigen Datensätze abrufen kann. Dieses Grundprinzip aus Order→Authorization→Capture→Refund ist ziemlich universell.
Ich vermute dass wir im Moment von zwei Ansätzen ausgehen und da das Problem liegt. Ihr wollt, dass der gesamten Zahlungsvorgang IM Shop bei der Bestellung steht bzw. durch Auswahl der jeweiligen Bestellung abgerufen werden kann. Das ist dann sinnvoll wenn nicht mit einer nachgelagerten WaWi und BuHa gearbeitet wird. Wenn aber mit einer nachgelagerten WaWi gearbeitet wird, dann ist im Prinzip ab dem Zeitpunkt der Datenübernahme aus dem Shop in die WaWi alles andere was im Shop steht egal, da die weitere Bearbeitung der Bestellung und alles was dazu gehört in der WaWi statt findet und nicht im Shop und die Buchhaltung denn entweder auch in der WaWi oder in einer angeschlossenen Buchhaltungssoftware (Datev, Addison, Lexware etc.) auch hier ist dann egal was im Shop weiter passiert. Da jede Zahlung einem Konto zugeordnet werden muss geht es rein um die Identifikation des Kontos, was durch die Transaktions-ID - sofern sie bei der Bestellung mit geführt wird - recht schnell und sicher möglich ist (Alternative wäre z.B. Name, eMail, Datum udn Betrag zur Identifizierung was dann aber ungenauer werden kann). Über die Zuordnung mittels Transaktions-ID erhalte ich eine Trefferquote von 100% sofern die Daten vor liegen. Grundsätzlich sollte die Zuordnung auch über die Payment-ID möglich sein, das Problem ist nun aber, dass nicht jedes System auf die Verarbeitung einer Payment-ID ausgelegt ist sondern mit der Transaktions-ID arbeiten will (selbstverständlich ist es Möglich die Zuordnung auch über die Payment-ID zu ermöglichen) und man diese also erst auf anderem Weg beschaffen muss. Das Unverständnis welches nun auf kommt liegt darin begründet, dass die Transaktions-ID nicht einfach bei der Bestellung im Shop mit gespeichert wird, insbesondere da diese bei der Paypal-Rückmeldung mit übertragen also direkt verfügbar ist. Der Aufwand wäre also recht gering und würde viel nach gelagerte Arbeit ersparen. Hinzu kommt dann, dass die Argumentation warum dies nicht gemacht wird einen gewissen Nachgeschmack hinterlässt - was man ebenfalls an manchen Reaktionen sehen kann. Ich denke wir brauchen keine Oberlehrer, sondern stressfreie Abläufe.
Was Aufgabe der WaWi Anbieter wäre Wenn ich das oben richtig gelesen habe, ist das nicht sinnig, und wird daher beim ausgeben im Shop Admin auf der Bestellseite direkt live abgerufen von PayPal und nicht aus der Shop DB. Du musst einen von 2 dazu bewegen die Tranaktions IDs im Shop zu Speichern oder den anderen die Tranaktions-IDs über die Payment-IDs abzurufen. Bei der WaWi wäre es sinniger, da das das Elternteil ist und nicht die einzelnen datensätze innerhalb der payment-ID. Die WaWi Leute müssen da ran. Paypal hats vorgemnacht, Gambio nutzt es - nun müssen die WaWi anbieter nachziehen (wie immer als letztes).
Nein, das ist immer sinnvoll. Wawi meint hier eher FiBu, aber welchen Begriff auch immer man wählt gibt es folgende Analogie zwischen beiden: Jedes System will irgendwas mit Zahlungsvorgängen machen. Shop, WaWi, FiBu, egal. Der Shop will anzeigen was schon da ist, in welchem Status der Zahlungsvorgang gesamt ist, wie es den Einzeltransaktionen darin geht. Die FiBu will sinnvoll Transaktionen verbuchen und einen buchhalterischen Kontext bilden. Dazu wäre die mit den Gesamtinformationen eines Zahlungsvorgangs genauso gut aufgestellt, sie müsste dann nur selbst den Schritt schaffen mit den erhaltenen Informationen etwas anzustellen. Der ganze Diskurs hier geht um folgendes: Wir speichern sinnvolle Daten, damit der Shop alles tun kann was er muss. Zahlungen, Teilzahlungen, Rückzahlungen, einen aktuellen Vorgangsgesamtstatus ausgeben, es mangelt an nichts. Für andere Anwendungen wäre die PayPal Vorgangs ID genauso ein idealer Startpunkt. Stattdessen: Die Wawis und FiBus wollen Daten aus der Mitte der Kette, weil diese Mitte bis 2012 mal der Oberteil der Kette war. Damals gab es keine grösseren Kontexte. Diese Daten aus der Mitte der Verarbeitungskette zu beschaffen ist der Vorgang der verortet werden soll. Unsere Ansicht dazu ist ganz klar zu definieren: Das ist Aufgabe der WaWis und FiBus, nicht unsere. Die haben sich, ebenso wie wir, anzupassen. Den Impuls liefern nicht wir, sondern PayPal, die sind so aufgestellt. Und nochmal: Wir wollen keine nonstatischen Laufzeitendaten speichern, die jederzeit vom gespeicherten Stand abweichen können. Das stellt PayPal so auf, nicht wir. Die liefern den Impuls. Wir wollen keinen halbgaren Stuss machen, nur um da Gagga-Fulfilment zu betreiben, das keiner Prüfung standhält.
Das sind ja auch 2 verschiedene Stiefel. Das was im Shop abgebildet ist, hat mit dem was du in der WAWI abbildest in dem Zusammenhang nichts zu tun. Im Shop geht es um eine reine Ansicht der Daten in dem Moment in dem ich die Bestellung anschaue. Die Payment-ID ist das Zuordnungsmerkmal was PayPal zur Verfügung stellt umd in der WAWI die passende Bestellung zu finden. Wen du dich mal von deinen Scheuklappen befreien würdest und über der Transaktionsnummer hinaus denkst, dann wird dann auch ein Schuh daraus und alles gibt einen Sinn.
Die FiBu und WaWi anbieter die PayPal abgleiche abrufen sind halt 2012 stehengeblieben und wollen da nix ändern, weil es die Zeit kosten würde. PayPal gibts vor, nu müssen die irgendwann nachziehen. Gambio hat klar gemacht, das es nur so sinnig ist und aktuell so wie PayPal es gerne hätte. nun müssen externe nachziehen und endlich ihre Hausaufgaben machen.
Mal so als kleiner Einschub, vielleicht hilft es bei der Diskussion irgendwie: Abruf der Daten über die aktuelle REST-Schnittstelle Nehmen wir mal an, wir kennen bereits die orders_id einer PayPal-Bestellung. Die orders_id zu finden, ist auch nicht schwierig, ginge hier aber gerade übers Thema hinaus. Wir bekommen dann die Basisdaten der Bestellung über einen simplen Abruf: GET https://www.derbeispielshop.tld/api.php/v2/orders/190311017 Ergebnis: Code: { "id": 190311017, "statusId": 1, "purchaseDate": "2019-05-28 10:57:51", "currencyCode": "EUR", "languageCode": "DE", "comment": "", "totalWeight": 84.05, "paymentType": { "title": "PayPal", "module": "paypal3" }, "shippingType": { "title": "Pauschale Versandkosten (Standard)", "module": "flat_flat" }, "customer": { "id": 2, "number": "2", "email": "kunokunde@gambio.de", "phone": "+49 421 3889890", "vatId": "", "status": { "id": 2, "name": "Neuer Kunde", "image": "customer_status.gif", "discount": 2, "isGuest": false } }, "addresses": { "customer": { "gender": "m", "firstname": "Kuno", "lastname": "Kunde", "company": "", "street": "Parallelweg 30", "houseNumber": "", "additionalAddressInfo": "", "suburb": "", "postcode": "28219", "city": "Bremen", "countryId": 81, "zoneId": 0, "b2bStatus": false }, "billing": { "gender": "m", "firstname": "Kuno", "lastname": "Kunde", "company": "", "street": "Parallelweg 30", "houseNumber": "", "additionalAddressInfo": "", "suburb": "", "postcode": "28219", "city": "Bremen", "countryId": 81, "zoneId": 0, "b2bStatus": false }, "delivery": { "gender": "m", "firstname": "Kuno", "lastname": "Kunde", "company": "", "street": "Parallelweg 30", "houseNumber": "", "additionalAddressInfo": "", "suburb": "", "postcode": "28219", "city": "Bremen", "countryId": 81, "zoneId": 0, "b2bStatus": false } }, "items": [ { "id": 17, "model": "SMPLTEST", "name": "Einfacher Testartikel", "quantity": 1, "price": 11, "finalPrice": 11, "tax": 19, "isTaxAllowed": true, "discount": 0, "shippingTimeInformation": "ca. 3-4 Tage", "checkoutInformation": "", "quantityUnitName": "", "attributes": [], "downloadInformation": [], "gxCustomizerData": [], "addonValues": { "productId": "2", "productType": "1", "identifier": "2" } }, { "id": 18, "model": "ABC123-m-gold", "name": "Testartikel", "quantity": 1, "price": 15, "finalPrice": 15, "tax": 19, "isTaxAllowed": true, "discount": 0, "shippingTimeInformation": "ca. 1 Woche", "checkoutInformation": "", "quantityUnitName": "", "attributes": [ { "id": 3, "name": "Größe", "value": "M", "price": 0, "priceType": "", "optionId": null, "optionValueId": null, "combisId": 4 }, { "id": 4, "name": "Farbe", "value": "Gold", "price": 0, "priceType": "", "optionId": null, "optionValueId": null, "combisId": 4 } ], "downloadInformation": [], "gxCustomizerData": [], "addonValues": { "productId": "1", "productType": "1", "identifier": "1x4" } }, { "id": 19, "model": "WaschMasch", "name": "Waschmaschine", "quantity": 1, "price": 299.98, "finalPrice": 299.98, "tax": 19, "isTaxAllowed": true, "discount": 0, "shippingTimeInformation": "ca. 3-4 Tage", "checkoutInformation": "", "quantityUnitName": "", "attributes": [], "downloadInformation": [], "gxCustomizerData": [], "addonValues": { "productId": "3", "productType": "1", "identifier": "3" } } ], "totals": [ { "id": 80, "title": "Warenwert:", "value": 325.98, "valueText": " 325,98 EUR", "class": "ot_subtotal", "sortOrder": 10 }, { "id": 81, "title": "2.00 % Rabatt::", "value": -6.52, "valueText": " -6,52 EUR", "class": "ot_discount", "sortOrder": 20 }, { "id": 82, "title": "Pauschale Versandkosten (Standard):", "value": 3.99, "valueText": " 3,99 EUR", "class": "ot_shipping", "sortOrder": 30 }, { "id": 83, "title": "Sperrgutzuschlag: 1x Waschmaschine: ", "value": 71.0787, "valueText": " 71,08 EUR", "class": "ot_gambioultra", "sortOrder": 31 }, { "id": 84, "title": "Gutscheine:", "value": 10, "valueText": "- 10,00 EUR", "class": "ot_gv", "sortOrder": 80 }, { "id": 85, "title": "inkl. 19% MwSt.:", "value": 62.99, "valueText": " 62,99 EUR", "class": "ot_tax", "sortOrder": 97 }, { "id": 86, "title": "<b>Summe</b>:", "value": 384.53, "valueText": "<b> 384,53 EUR</b>", "class": "ot_total", "sortOrder": 99 } ], "statusHistory": [ { "id": 35, "statusId": 0, "dateAdded": "2019-05-28 10:57:51", "comment": "", "customerNotified": true }, { "id": 36, "statusId": 1, "dateAdded": "2019-05-28 10:58:00", "comment": "Checkout-Modus: ECS", "customerNotified": false } ], "addonValues": { "customerIp": "", "downloadAbandonmentStatus": "0", "serviceAbandonmentStatus": "0", "ccType": "", "ccOwner": "", "ccNumber": "", "ccExpires": "", "ccStart": "", "ccIssue": "", "ccCvv": "123" }, "_links": { "status": "https://www.derbeispielshop.tld/api.php/v2/customer_groups/1", "payment_details": "https://www.derbeispielshop.tld/api.php/v2/orders/190311017/payment_details", "tracking_codes": "https://www.derbeispielshop.tld/api.php/v2/orders/190311017/tracking_codes" } } Unten bei den Links finden wir den URL für die weiterführenden Daten zur Zahlung. Die rufen wir nun auch ab: GET https://www.derbeispielshop.tld/api.php/v2/orders/190311017/payment_details Und wir bekommen: Code: { "module": "paypal3", "details": { "mode": "sandbox", "payment_id": "PAYID-LTWPPCA76B984077V6190319", "details": { "id": "PAYID-LTWPPCA76B984077V6190319", "intent": "sale", "state": "approved", "cart": "5AK18511J08687606", "payer": { "payment_method": "paypal", "status": "VERIFIED", "payer_info": { "email": "kunokunde@gambio.de", "first_name": "Thekla", "last_name": "Tester", "payer_id": "5T2TUZ9XXXXXX", "shipping_address": { "recipient_name": "Kuno Kunde", "line1": "Parallelweg 30", "city": "Bremen", "state": "", "postal_code": "28219", "country_code": "DE" }, "phone": "7884334331", "country_code": "DE" } }, "transactions": [ { "amount": { "total": "384.53", "currency": "EUR", "details": { "subtotal": "325.98", "tax": "0.00", "shipping": "3.99", "insurance": "0.00", "handling_fee": "54.56", "shipping_discount": "0.00" } }, "payee": { "merchant_id": "24GRU7DXXXXXX", "email": "m.bruchmann@gambio-support.de" }, "description": "DevShop 3.13", "invoice_number": "190311017", "item_list": { "items": [ { "name": "Einfacher Testartikel", "sku": "SMPLTEST", "price": "11.00", "currency": "EUR", "tax": "0.00", "quantity": 1 }, { "name": "Testartikel", "sku": "ABC123", "price": "15.00", "currency": "EUR", "tax": "0.00", "quantity": 1 }, { "name": "Waschmaschine", "sku": "WaschMasch", "price": "299.98", "currency": "EUR", "tax": "0.00", "quantity": 1 } ], "shipping_address": { "recipient_name": "Kuno Kunde", "line1": "Parallelweg 30", "city": "Bremen", "state": "", "postal_code": "28219", "country_code": "DE" } }, "related_resources": [ { "sale": { "id": "78R428083C540382B", "state": "refunded", "amount": { "total": "384.53", "currency": "EUR", "details": { "subtotal": "325.98", "tax": "0.00", "shipping": "3.99", "insurance": "0.00", "handling_fee": "54.56", "shipping_discount": "0.00" } }, "payment_mode": "INSTANT_TRANSFER", "protection_eligibility": "ELIGIBLE", "protection_eligibility_type": "ITEM_NOT_RECEIVED_ELIGIBLE,UNAUTHORIZED_PAYMENT_ELIGIBLE", "transaction_fee": { "value": "5.73", "currency": "EUR" }, "parent_payment": "PAYID-LTWPPCA76B984077V6190319", "create_time": "2019-05-28T08:57:58Z", "update_time": "2019-05-28T09:42:11Z", "links": [ { "href": "https://api.sandbox.paypal.com/v1/payments/sale/78R428083C540382B", "rel": "self", "method": "GET" }, { "href": "https://api.sandbox.paypal.com/v1/payments/sale/78R428083C540382B/refund", "rel": "refund", "method": "POST" }, { "href": "https://api.sandbox.paypal.com/v1/payments/payment/PAYID-LTWPPCA76B984077V6190319", "rel": "parent_payment", "method": "GET" } ] } }, { "refund": { "id": "0N0104161V9344152", "state": "completed", "amount": { "total": "-384.53", "currency": "EUR" }, "parent_payment": "PAYID-LTWPPCA76B984077V6190319", "sale_id": "78R428083C540382B", "create_time": "2019-05-28T09:40:49Z", "update_time": "2019-05-28T09:42:11Z", "links": [ { "href": "https://api.sandbox.paypal.com/v1/payments/refund/0N0104161V9344152", "rel": "self", "method": "GET" }, { "href": "https://api.sandbox.paypal.com/v1/payments/payment/PAYID-LTWPPCA76B984077V6190319", "rel": "parent_payment", "method": "GET" }, { "href": "https://api.sandbox.paypal.com/v1/payments/sale/78R428083C540382B", "rel": "sale", "method": "GET" } ] } } ] } ], "create_time": "2019-05-28T08:55:36Z", "update_time": "2019-05-28T09:42:11Z", "links": [ { "href": "https://api.sandbox.paypal.com/v1/payments/payment/PAYID-LTWPPCA76B984077V6190319", "rel": "self", "method": "GET" } ] } } } Und voilà, schon hat man sämtliche Daten, die PayPal zu der Payment-ID ausspuckt, die der Bestellung zugeordnet ist. Inklusive der Sale-Transaktion und ihrer TransactionID. Das ist genau das, was eine FiBu-/WaWi-/ERP-/Whatever-Software tun würde, wenn sie die REST-Schnittstelle des Shops benutzt.
Also müssen die nicht mal selbst an PP anfragen sondern die RESTapi vom SHop macht das bei abfrage live für die? Oben hatte ich es so verstanden das die das von PP abholen sollten. Dann wäre ja die Aufgabe die WaWi anbieter dazu zu bringen generell RESTapi vom SHop zu nutzen. statt eigene Module.
Genau so ist es. Das bezieht sich nur auf des Szenario, wenn man in einer starren Datenstruktur, in der vormals eine Transaction-ID übertragen wurde, nun die Payment-ID überträgt und dann doch die Transaction-ID (oder weitere Angaben) braucht.
Und wenn Du mal richtig lesen würdest, dann hättest Du vielleicht auch gemerkt, dass ich versucht habe, das Problem, was einige Leute mit der Anbindung WaWi/Shop haben zu erklären, weil ich den Eindruck hatte, dass dies nicht bei allen beteiligten richtig verstanden wurde. Aber was solls, bringt alles nichts.