ktwdallas
asked on
Updating Paypal after authorization
Okay, so I'm not sure this is possible but I thought I'd ask.
We're using Paypal Payments Pro (with PHP code), so this is all with using paypal as a merchant account via CURL -- not redirecting the customer.
In our order system, I have two sets of numbers, one is a OrderID which is a primary key and sequential. Orders can be created and sometimes deleted if a person decides not to complete the order. The second number is the InvoiceID which is only generated once payment is actually successful, in order not to generate gaps in numbers or voids. Once a payment is done, I find the MAX(InvoiceID), add 1 and update the Order record.
The problem is with Paypal. I'd like to put the Invoice number as part of the Description since our accounting dept looks at that. But it's circular logic -- I don't have the Invoice number until the Paypal transaction is successful, and once I have it, Paypal is done. So is there a way to go back to Paypal and update that description (or any field) after the fact?
We're using Paypal Payments Pro (with PHP code), so this is all with using paypal as a merchant account via CURL -- not redirecting the customer.
In our order system, I have two sets of numbers, one is a OrderID which is a primary key and sequential. Orders can be created and sometimes deleted if a person decides not to complete the order. The second number is the InvoiceID which is only generated once payment is actually successful, in order not to generate gaps in numbers or voids. Once a payment is done, I find the MAX(InvoiceID), add 1 and update the Order record.
The problem is with Paypal. I'd like to put the Invoice number as part of the Description since our accounting dept looks at that. But it's circular logic -- I don't have the Invoice number until the Paypal transaction is successful, and once I have it, Paypal is done. So is there a way to go back to Paypal and update that description (or any field) after the fact?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Ray, you misunderstood. The OrderID is the primary key, but there are no requirements there. What I was saying was that records could be deleted (because orders are abandoned before they're paid for and just through maintenance, we drop those rows). So there are missing OrderIDs, that doesn't matter.
There is a second field, a simple int field, which is NULL until we assign an InvoiceID to it upon payment for an order. That's where we can't be missing numbers. So our table might be something like below. We're missing OrderIDs from deleted records, but who cares. Only successfully paid records are assigned an InvoiceID (again, upon completion, by finding the last used and incrementing one).
I could assign an invoiceID the moment I bill, but if it's a decline and they never come back, then I have an outstanding Invoice the customer never intends to pay, which we have to show as Void and you don't want to have tons of voided Invoices on your books.
(Obviously our real table has many more field.) The Description also goes to the customer on their Paypal screen (which is the real reason I wanted it there). Yes I could just switch to the Order number, which is what will be done since neeraj523 answered the question I was asking.
There is a second field, a simple int field, which is NULL until we assign an InvoiceID to it upon payment for an order. That's where we can't be missing numbers. So our table might be something like below. We're missing OrderIDs from deleted records, but who cares. Only successfully paid records are assigned an InvoiceID (again, upon completion, by finding the last used and incrementing one).
I could assign an invoiceID the moment I bill, but if it's a decline and they never come back, then I have an outstanding Invoice the customer never intends to pay, which we have to show as Void and you don't want to have tons of voided Invoices on your books.
(Obviously our real table has many more field.) The Description also goes to the customer on their Paypal screen (which is the real reason I wanted it there). Yes I could just switch to the Order number, which is what will be done since neeraj523 answered the question I was asking.
OrderID InvoiceID CustomerName TransactionResult
100 NULL Bob
104 9000 Julie X238DAG293AS3
105 NULL Tom
107 9001 Bill E493839D93840
110 9002 Mary UD338374DJGH3ASKER
The simple "no" was what I was looking for. Thanks.
If the programming needs the OrderID to be the primary key, sequential and without gaps, it is not a technically competent design. This is a way to be certain that disaster is not left to chance. It is axiomatic that data base keys have no external meaning - they are present in the data base tables to implement the relational nature of data bases, but nothing else. The world is littered with the dessicated husks of applications that tried to have "meaningful keys." So please don't do that.
I suggest that you keep separate columns in your own tables for after-the-fact data assignments. And educate your accounting department about the meaning of a "description" -- it is there to tell the client about the product, not to give the accounting department an order sequence number. The sequence of orders and invoices will always be available from the DATETIME fields of the PayPal transaction records. The PayPal-assigned order identification numbers will be there, too. These are the fields you should depend on.