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?
Who is Participating?
neeraj523Connect With a Mentor Commented:
In first shot, i can say paypal dosnt provide any such facility to update the already posted order details..

I will suggest to create the invoice before sending payment request to paypal and send invoiceid to paypal.. But you maintain additional field in invoice table such is IsPaid with yes/no option.. First time when you add invoice, keep it as IsPaid=No and once get payment confirmation from Paypal, update this record with status Yes.

Ray PaseurCommented:
Wow, this sounds scary.  Did you find something in the PayPal Developer documentation references that guided you to this design pattern?  If so, let's call it out right now.

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.

ktwdallasAuthor Commented:
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.

OrderID		InvoiceID		CustomerName		TransactionResult
100			NULL			Bob
104			9000			Julie				X238DAG293AS3
105			NULL			Tom
107			9001			Bill				E493839D93840
110			9002			Mary				UD338374DJGH3

Open in new window

ktwdallasAuthor Commented:
The simple "no" was what I was looking for. Thanks.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.