Prasmul ELI Career Companion

V0's Vue interface did not meet the SEO team's search-visibility requirements, so V1 moved the public experience to server-rendered Laravel pages. The application also had to connect an existing Google sign-in experience and a private SSO package used for the CC and CDC service context without introducing a separate account path.

I contributed frontend work across both versions, improved the existing social sign-in experience, and made provider links available in shared login surfaces. On the backend, I integrated the private SSO package at the application boundary so the existing identity flow could enter the CC and CDC context.

V1 could serve indexable Laravel-rendered pages while preserving a single application login path into the CC and CDC context. The SEO team checked indexing against the sitemap after the move and confirmed it. They raised the requirement in the first place, so the confirmation came from the people who would know.

A Midtrans checkout began as a pending local order. Provider callbacks then had to be matched to that order and checked before payment state could grant access to direct courses or every course inside a purchased bundle.

I implemented Snap-token creation and configurable sandbox and production endpoints. The callback layer handled normal responses, webhooks, and provider-specific return formats; reconstructed the SHA-512 signature; queried Midtrans's status API; and distinguished capture or settlement from pending, denied, canceled, expired, and failed transactions.

For a verified successful transaction, the backend completed the existing order, recorded earnings, enrolled the learner, generated the invoice PDF, and queued the confirmation email.

Course access and invoicing followed confirmed Midtrans state instead of a browser return alone. Successful direct-course and bundle payments created the corresponding enrollments, while pending and failed states remained separate. I walked each transaction state through the Midtrans sandbox, one at a time, and watched what the backend did with each. Reading the callback code would have suggested the same separation between settled and unsettled states, but watching it happen is different evidence.

CoursePlayer was a separate Laravel application with its own users and access tokens. New Career Companion accounts had to be provisioned there, existing accounts needed a backfill path, and a learner opening paid content should not have to complete a second interactive login.

I implemented both sides of the account-provisioning contract: Career Companion sent profile data through signed registration requests, and CoursePlayer accepted the fields and returned its local user representation and token. New registrations triggered provisioning without making a CoursePlayer failure block the local account, while a console command could process existing users and report failures per account. The HTTP client retried timeouts up to three times.

Before handing off content, Career Companion checked ownership of the direct course or its bundle, requested a CoursePlayer access token, cached it per user for 60 minutes, and redirected to the original CoursePlayer content URL.

New and existing Career Companion users had explicit provisioning paths into CoursePlayer. Learners with course access could open the corresponding content without a second interactive sign-in, and one failed account did not stop the bulk backfill from continuing. I ran the migration command over real Career Companion users. It carried on past the accounts CoursePlayer rejected as already existing, reporting each failure on its own, and I watched it do that. The resilience is something the run showed me, not something I inferred from the code.

The university needed to grant course access through vouchers without bypassing the platform's order history, enrollment model, or administrative permissions.

I implemented unique vouchers with active, expiry, and usage state; creator and redeemer ownership; bulk code creation; status controls; and permission-aware administration. Redemption checked that the user was a student, that the voucher was valid, and that the learner did not already own the course. A successful claim recorded the redeemer, created a completed voucher order and item, and attached the learner to the course.

Voucher access became a normal course enrollment with an order record, not a separate entitlement path. Administrators could create and manage codes through the same role-based backend used for the rest of the platform.